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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document identifies the Mobile-services Switching Centre/Interworking functions (MSC/IWFs) and 
requirements to support interworking between: 

i) PLMN and PSTN; 

ii) PLMN and ISDN; 

within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document identifies the Mobile-services Switching Centre/Interworking Functions (MSC/IWFs) and 
requirements to support interworking between: 

a) PLMN and PSTN; 

b) PLMN and ISDN; 

for circuit switched services in the PLMN. It is not possible to treat ISDN and PSTN as one type of network, even when 
both ISDN and PSTN subscribers are served by the same exchange because of the limitations of the PSTN subscribers 
access i.e. analogue connection without D-channel signalling. 

Within the present document, the requirements for voice and non-voice (data) calls are considered separately. 

From R99 onwards the following services are no longer required by a PLMN: 

the dual Bearer Services "alternate speech/data" (BS 61) and "speech followed by data" (BS 81); 

the dedicated services for PAD (BS 4x) and Packet access (BS 5x); 

the single asynchronous and synchronous Bearer Services (BS 21. .26, BS 31.. 34). 
From Rel-4 onwards the following services are no longer required by a PLMN: 

the synchronous Bearer Service non-transparent (BS 30 NT); 

the Basic Packet access; 

Non-transparent facsimile (TS 61/62 NT) for the A/Gb mode and GERAN lu mode. 

If a PLMN still provides these services it shall fulfil the specification of former releases. 

The present document is valid for a PLMN in A/Gb mode as well as in lu mode. If text applies only for one of these 
systems it is explicitly mentioned by using the terms "A/Gb mode" and "lu mode". If text applies to both of the systems, 
but a distinction between the ISDN/PSTN and the PLMN is necessary, the term "PLMN" is used. 

NOTE: The Gb interface does not play any role in the scope of the present document although the term "A/Gb 
mode" is used. 
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[50] Mobile Internet Access Forum: "PIAFS Specification Ver. 1.1, 2.1". 

[51] ITU-T Recommendation V.8: "Procedures for starting sessions of data transmission over the 

public switched telephone network" . 
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[52] 3GPP TS 26.1 1 1: "Codec for circuit switched multimedia telephony service; Modifications to 

H.324". 

[53] Void 

[54] ITU-T Recommendation H.223 (03/96): "Multiplexing protocol for low bit rate multimedia 

communication" . 

[55] ITU-T Recommendation H.223 (Annex A) (02/98): "Multiplexing protocol for low bit rate 

multimedia communication over low error-prone channels". 

[56] ITU-T Recommendation H.223 (Annex B) (02/98): "Multiplexing protocol for low bit rate 

multimedia communication over moderate error-prone channels". 

[57] ITU-T Recommendation H.223 (Annex C) (02/98): "Multiplexing protocol for low bit rate 

multimedia communication over highly error-prone channels". 

[58] ITU-T Recommendation H.324: "Terminal for low bit-rate multimedia communication". 

[59] ITU-T Recommendation H.221: "Frame structure for a 64 to 1920 kbit/s channel in audiovisual 

teleservices". 

[60] ITU-T Recommendation H.242: "System for establishing communication between audiovisual 

terminals using digital channels up to 2 Mbit/s". 

[61] ITU-T Recommendation H.245: "Control protocol for multimedia communication". 

[62] ITU-T Recommendation V.8 bis: "Procedures for the identification and selection of common 

modes of operation between data circuit-terminating equipments (DCEs) and between data 
terminal equipments (DTEs) over the public switched telephone network and on leased point-to- 
point telephone-type circuits". 

[63] ITU-T Recommendation V.21 (1 1/88): "300 bits per second duplex modem standardized for use in 

the general switched telephone network". 

[64] ITU-T Recommendation V.22bis (1988): "2400 bits per second duplex modem using the 

frequency division technique standardized for use on the general switched telephone network and 
on point-to-point 2-wire leased telephone-type circuits". 

[65] ITU-T Recommendation V.23 (1 1/88): "600/1200-baud modem standardized for use in the general 

switched telephone network". 

[66] ITU-T Recommendation V.26 (1 1/88): "2400 bits per second modem standardized for use on 4- 

wire leased telephone-type circuits". 

[67] ITU-T Recommendation V.26 bis (1 1/88): "2400/1200 bits per second modem standardized for 

use in the general switched telephone network" . 

[68] ITU-T Recommendation V.26 ter (1 1/88): "2400 bits per second duplex modem using the echo 

cancellation technique standardized for use on the general switched telephone network and on 
point-to-point 2-wire leased telephone-type circuits". 

[69] ITU-T Recommendation V.27 (1 1/88): "4800 bits per second modem with manual equalizer 

standardized for use on leased telephone-type circuits". 

[70] ITU-T Recommendation V.27 bis (1 1/88): "4800/2400 bits per second modem with automatic 

equalizer standardized for use on leased telephone-type circuits". 

[71] ITU-T Recommendation V.29 (1 1/88): "9 600 bits per second modem standardized for use on 

point-to-point 4-wire leased telephone-type circuits". 

[72] ITU-T Recommendation Q.921 (09/97): "ISDN user-network interface - Data link layer 

specification" . 

[73] ITU-T Recommendation X.21 (09/92): "Interface between Data Terminal Equipment (DTE) and 

Data Circuit-terminating Equipment (DCE) for synchronous operation on public data networks". 
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[74] ITU-T Recommendation X.25 (10/96): "Interface between Data Terminal Equipment (DTE) and 

Data Circuit - terminating Equipment (DCE) for terminals operating in the packet mode and 
connected to public data networks by dedicated circuit". 

[75] ITU-T Recommendation X.28 (12/97): "DTE/DCE interface for a start-stop mode Data Terminal 

Equipment accessing the Packet Assembly/Disassembly facility (PAD) in a public data network 
situated in the same country". 

[76] ITU-T Recommendation X.31 (1 1/95): "Support of packet mode terminal equipment by an ISDN". 

[77] ITU-T Recommendation X.75 (10/96): "Packet-switched signalling system between public 

networks providing data transmission services". 

[78] ISO 2110 (1989): "Information technology - Data communication - 25-pole DTE/DCE interface 

connector and contact number assignments". 

[79] ISO/IEC 6429 (1992): "Information technology - Control functions for coded character sets". 

[80] 3GPP TS 29.415: "Core Network Nb Interface User Plane Protocols" 

[81] ITU-T Recommendation 1.366.2: "AAL type 2 service specific convergence sublayer for 

trunking". 

[82] 3GPP TS 29.232: "Media Gateway Controller (MGC); Media Gateway (MGW) interface; Stage 3" 

[83] 3GPP TS 23.172: "Technical ReaHsation of the Circuit Switched (CS) multimedia service; 

UDI/RDI fallback and service modification; Stage 2" 

[84] ITU-T Recommendation E.163 (1 1/88): "Numbering plan for the international telephone service". 

[85] ITU-T Recommendation E.164 (02/05): "The international public telecommunication numbering 

plan". 

[86] 3GPP TS 27.001 : "General on Terminal Adaption Functions (TAP) for Mobile Station (MS)". 

[87] ITU-T Recommendation 1.363.2: "B-ISDN ATM Adaptation Layer specification : Type 2 AAL". 

[88] ITU-T Recommendation 1.366.2: "AAL type 2 service specific convergence sublayer for narrow- 

band services". 

[89] ITU-T Recommendation Q.2630. 1 (12/99): "AAL type 2 signalUng protocol (Capability Set 1)". 

[90] 3GPP TS 23.202: "Circuit switched data bearer services". 

[91] 3GPP TS 23.153: "Out of band transcoder control; Stage 2". 

[92] IETF RFC 4040: "RTP Payload Format for a 64 kbit/s Transparent Call " 

[93] 3GPP TS 29.414: "Core network Nb data transport and transport signalhng ". 

[94] IETF RFC 2198: "RTP Payload for Redundant Audio Data". 

[95] IETF RFC 355 1 : "RTP Profile for Audio and Video Conferences with Minimal Control". 

[96] ITU-T Recommendation T.38: "Procedures for real-time Group 3 facsimile communication over 

IP networks" 

[97] IETF RFC 3362: "Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration" 

[98] IETF RFC 4566: "SDP: Session Description Protocol". 

[99] 3GPP TS 23.23 1 : "SIP-I based Circuit Switched Core Network; Stage 2" 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

bearer capability information: specific information defining the lower layer characteristics required within the 
network. 

low layer compatibility information: information defining the lower layer characteristics of the terminal. 

high layer compatibility information: information defining the higher layer characteristics of the terminal. 

compatibility information: this term subsumes the entirety of Bearer Capability, Low Layer Compatibility, High 
Layer Compatibility, Progress Indicator and Address Information conveyed out-of-band prior to call establishment for 
the support of compatibility checking and terminal/function/service selection at the ISDN-type user-network interface. 

protocol identifier: information defining the specific protocols utilized for the support of data transfer by a terminal. 

progress indicator: information supplied to indicate to the terminal that network interworking has taken place. 

out-of-band parameter exchange: information exchanged via an associated or non-associated signalling link e.g. SS 
No 7. 

PSTN: subscriber to network interface supports only analogue terminals. 

ISDN: subscriber to network interface supports digital or analogue terminals, plus a standardized user to network 
associated signalling system and a standardized internetwork signalling system. 

autobauding type 1: this information element value may be contained in the setup or call confirm messages from the 
UE in association with a non transparent data service. This implies that the MSC/IWF may select any speed and modem 
type according to what it can negotiate with the remote modem on the PSTN/ISDN. The parameters User Rate and 
FNUR (Fixed Network User Rate), if present, has no meaning when Modem Type is autobauding type 1. 

multi self selecting speed modem: this term applies to V series modems capable of handling one or more lower speeds 
as a fall back position. When such a modem is requested in the call setup or call confirm message from the UE in 
association with a non transparent service, the MSC/IWF may select any of the speeds supported according to the 
negotiation with the remote modem on the PSTN/ISDN. The parameters User Rate and FNUR (Fixed Network User 
Rate), if present, has no meaning when Modem Type is autobauding type I . 

unrestricted 64 kbit/s network: a digital network which has 64 kbit/s octet-structured Information Transfer Capability 
(ITC) with no restrictions on the contents of each octet. 

restricted 64 kbit/s network: ITU-T Recommendation 1.464 defines '"restricted 64 kbit/s transfer capability" as 
"64 kbit/s octet-structured capability with the exception that an all-zero octet is not permitted". In the present document, 
the term "restricted 64 kbit/s network" refers not only to networks with the ITU-T Recommendation 1.464 restriction but 
also to those in which the 8th bit of each octet is unusable for data transmission. 

directly connected restricted 64 kbit/s network: restricted 64 kbit/s network which is connected directly to the 
MSC/IWF. 

indirectly connected restricted 64 kbit/s network: restricted 64 kbit/s network which is connected to the MSC/IWF 
via an unrestricted 64 kbit/s network. 

EDGE channel: general term referring to channels based on 8PSK modulation; i.e. TCH/F28.8, TCH/F32.0, and 
TCH/F43.2. 

A/Gb mode: a system or a subsystem operates in A/Gb mode if an A or Gb interface is used between the radio access 
network and the core network. 

lu mode: a system or a subsystem operates in lu mode if an lu-CS or lu-PS interface is used between the radio access 
network and the core network. It operates in UTRAN lu mode if UTRAN is used as radio access network. It operates in 
GERAN lu mode if GERAN is used as radio access network. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 and the following apply: 

ADPCM Adaptive Differential Pulse Coded Modulation 

BS Bearer Service 

DP Dial Pulse 

DSSl Digital Subscriber SignalUng 1 

FTM Frame Tunnelling Mode 

ITC Information Transfer Capability 

LE Local Exchange 

NT Network Termination 

NT non-transparent 

PABX Private Automatic Branch Exchange 

PIAFS PHS Internet Access Forum Standard 

PPP Point to Point Protocol 

SPC Stored Program Control 

SS No.7 Signalling System No.7 

T transparent 

TE Terminal Equipment 

TA Terminal Adaptor 

TS Teleservice 

TS Technical Specification 

TUP Telephone User Part (of Signalling System No.7) 

UNI User Network Interface 



4 Introduction 

Since the numbering plan for the ISDN era (E.164) includes the numbering plan for the telephone network (E. 163), it is 
not possible to distinguish by the number whether a given subscriber is a PSTN or ISDN subscriber. Further, in some 
countries both PSTN and ISDN subscribers will be connected to the same exchange, so the only difference for this type 
of combined network will be in the nature of the customer access. In the present document a PSTN is considered to 
support only an analogue interface towards the subscriber. An ISDN shall be considered to support digital interface 
towards the subscriber. In addition, the ISDN is considered to support a standardized outband signalling protocol both 
between the subscriber and the network and within the network, i.e. DSSl and ISUP, thus enabling the generation and 
transport of Compatibility Information for compatibility checking and terminal/function/service selection at the 
user-network interface as well as for MSC/IWF selection. 

There now exist networks which do not fall into either of these categories in that they provide for digital connectivity 
from subscriber to subscriber through the network. The subscribers have access to a wide range of services by a limited 
set of standard multi-purpose user network interfaces. However, these networks do not support the standardized 
inter-exchange signalling protocol throughout, in that they are e.g. using TUP or National User Part (NUP). These types 
of network support 64 kbit/s connections, so in service support are comparable to ISDN, however, the signalling system 
provided may not support transport of all Compatibility Information allowed for in the standardized ISDN signalling. 
The present document will therefore identify interworking to PSTN and ISDN on the principle of the network 
characteristics as identified in the previous paragraph. The aforementioned existing networks then constitute one 
particular case in the ISDN interworking scenarios. These cases will be itemized when the implication of the various 
degrees of exhaustiveness of the Compatibility Information - delivered via the ISDN - used for deducting a PLMN 
Basic Service needs to be set forth. 

When two dissimilar networks are required to interwork in order to support a communication between two subscribers, 
one on each network, a number of Interworking Functions (MSC/IWFs) are required to support the communication. 
Some of these are related to the differences in signalling and are dealt with in 3GPP TS 49.003. 

Examples of other aspects of interworking are: 

a) the need or otherwise of echo control devices; 

b) the need or otherwise of modem pools and network-based rate adaptation. 
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For the purposes of determining the required MSC/IWFs, it is necessary, however, to consider separately each type of 
interworking (i.e. PLMN-ISDN and PLMN-PSTN) since, in the worst case, "PSTN" could refer to an essentially 
analogue network with electromechanical switching not controlled by software and without common-channel 
signalling. 

Some facilities associated with alternate speech and facsimile group 3 may not be available with version 1 of the MAP 
(3GPP TS 09.02). Version 1 of the Mobile Application Part (MAP) does not support in-call modification and channel 
mode modification following an inter-MSC handover. 



Void 



6 Network Characteristics 

6.1 Key Characteristics of Networks Concerned 

Table 1 : Key Characteristics of Networks Concerned 



Characteristic 


PLMN 


ISDN 


PSTN 


Subscriber Interface 


Digital 


Digital 


Analogue 


User-network signalling 


3GPP TS 24.008 


DSS1, other UNIs 


loop-disconnect and DTIVIF 


User-terminal equipment 
supported 


see 3GPP TS 24.002 


Digital TE 
(ISDN NT, TE1 or 
TE2+TA) 
see e.g. 1.411 


Analogue TE (e.g. dial pulse 
telephones PABXs modem 
equipped DTEs) 


Inter-exchange signalling 


SS No.7 ISUP 
TUP+, MAP 


SS No.7 ISUP 
TUP+, TUP, NUP 


Channel associated 
(e.g. R2, No.4, No. 5) or 
common channel (e.g. No. 6) 


Transmission facilities 


Digital 


Digital 


Analogue 


Exchange types 


Digital 


Digital 


Analogue/digital 


Information transfer mode 


Circuit 


Circuit 


Circuit 


Information transfer capability 


Speech, digital 
unrestricted, alternate 
speech/ group 3 fax etc. 


Speech, digital 
unrestricted, 3,1 kHz 
audio, video etc. 


3,1 kHz audio 
(voice/voice- band data) 



6.1.1 Characteristics of PLMNs 

The PLMN is fully defined in the Technical Specifications summarised in 3GPP TS 41.003 for a 2°'' generation PLMN 
(A/Gb mode) or in 3GPP TS 21.103 for a 3"* generation PLMN (lu mode). 

6.1 .2 Cinaracteristics of PSTNs 

Because of the efforts at an early stage to standardize ISDNs in different countries, the differences between any two 
ISDNs will be small compared with the differences between PSTNs, which have evolved in different ways in different 
countries. In some cases the evolution has occurred over many decades, and therefore each PSTN is distinct, and for a 
recommendation on interworking, it is necessary to make certain assumptions about a generalized PSTN. 

Whilst the key characteristics of PSTNs are given in table 1 above, the specific MSC/IWFs needed to allow 
interworking between a PLMN and a PSTN will depend on the nature of the PSTN concerned. 

Table 2 gives a number of categories that can be used to classify PSTNs and a number of possibilities within each 
category. 
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Table 2: Characteristics of PSTNs 



Category 


Possibilities within Category 


Type of subscriber 
signalling 


a) PSTN with loop disconnect subscriber signalling (10 pps) 


b) PSTN with DTMF subscriber signalling 


Type of interexchange 
signalling 


a) PSTN with channel-associated signalling 


b) PSTN with common-channel signalling 


Type of interexchange 
transmission 


a) Analogue 


b) Digital 


Type of exchange 
switching 


a) PSTN with electro-mechanical switching 


b) PSTN with electronic (non-digital) switching 


c) PSTN with electronic digital switching 


Type of exchange 
control 


a) Non-SPC 


b)SPC 


NOTE: Under each category, it is possible that a PSTN will have a combination of the possibilities 
rather than only one. 



6.1 .3 Characteristics of ISDN 

For the "standardized ISDN" in principle taken into account here, these are defined in the ETS/ITU-T-series. 



7 Interworking classifications 

7.1 Service interworking 

Service interworking is required when the Teleservices at the calling and called terminals are different. No service 
interworking, except for facsimile group 3 (Teleservice 61 or 62 interworking with standard facsimile group 3 service), 
has been identified as a requirement of the PLMN system for PSTN/ISDN network based services. 



7.2 



Network interworking 



Network interworking is required whenever a PLMN and a non-PLMN together are involved to provide an end to end 
connection and may be required in instances of PLMN to PLMN connections. 

The concept of Bearer Services was developed for the ISDN and has been extended to the PLMN. A bearer service is 
defined (in 3GPP TS 22.001) as. 

A type of telecommunication service that provides the capability for the transmission of signals between user-network 
interfaces. 

Bearer services are described by a number of attributes, where an attribute is defined as a specified characteristic of an 
object or element whose values distinguish that object or element from others. 

For the purpose of the present document, a PSTN is assumed to provide a bearer service which equates to an ISDN 
3,1 kHz audio bearer service. 

Refer to 3GPP TS 22.002 for complete list of bearer services. Refer to 3GPP TS 24.008 for coding of Bearer 
Capabilities. Refer to 3GPP TS 27.001 for the allowed combinations of parameter value settings. 
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Table 3: Bearer Service Interworking 



Bearer service category in PLMN 


Bearer Service in PLMN 


Bearer service in 
ISDN 


Service in PSTN 


Circuit mode unstructured with 
unrestricted digital capability 
Transparent and Non-transparent 


Asynchronous Data general 


Get mode structured 
64 kbit/s unrestricted 


Not Applicable 


Circuit mode unstructured with 
unrestricted digital capability 
Transparent 


Synchronous Data general 


3,1 kHz Audio Ex PLMN 
Transparent and Non-transparent 


Asynchronous Data general 


Cct Mode 
3,1 kHz Audio 


Cct Mode 
3,1 kHz Audio 


3,1 kHz Audio Ex PLMN 
Transparent 


Synchronous Data general 



Table 4: Network interworking of Teleservices 



Teleservice in 
PLMN 


Lower layer capabilities 

addressed in the PLMN Bearer 

Capabilities IE 


Bearer service 
in ISDN 


Service 
in PSTN 


Telephony 


Unstructured with speech capability 


Speech or Cct mode 
3,1 kHz audio 


Cct Mode 
3,1 kHz audio 


Emergency calls 


Unstructured with speech capability 


Alternate speech/ 
facsimile group 3 


Data Cct duplex synchronous (A/Gb 
mode) / asynchronous (UTRAN lu 
mode) access 
alternate speech 
group 3 fax 


Cct mode 3,1 kHz 
audio 


Cct mode 3,1 kHz 
audio 


Automatic 
Facsimile group 3 


Data Cct duplex synchronous (A/Gb 
mode) / asynchronous (UTRAN lu 
mode) access 
group 3 fax 


Cct mode 3,1 kHz 
audio 



This table does not identify any relationship between Teleservices in the PLMN with those in the ISDN/PSTN, it is 
merely to identify the interworking of the lower network layers of that teleservice with the network layers i.e. bearer 
service in the ISDN/PSTN. 



7.3 Signalling interworking 



See3GPPTS49.003[31]. 



7.4 



Numbering 



See3GPPTS23.003[35] 

7.5 Supplementary service interworking 

For general aspects of supplementary services refer to 3GPP TS 22.004[34] and 23.011 [37]. 

Not every supplementary service may be used in combination with each basic service. The applicability of each 
supplementary service for a basic service is defined in 3GPP TS 22.004[34]. 



8 Compatibility and subscription checking 

Compatibility checking is carried out on the following items: 

a) Low layer compatibility - utilizing low layer compatibility and bearer capability information elements. 

b) High layer compatibility - utilizing high layer compatibility information element. 
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The use of the progress indicator for compatibility checking is outside the scope of the present document. 

Indication of compatibility requirements is carried out as described in subclauses 9.2.2 and 10.2.2. 

For subscription checking, relevant for the interworking described in clauses 9 and 10 of the present document, refer to 
3GPPTS 22.001. 

9 Interworking to PSTN 

9.1 Speech Calls 

9.1 .1 Interworking indications to PLMN terminal 

An indication to inform the PLMN terminal that: 

i) instead of receiving out-of-band indications for certain types of failure conditions, a tone or announcement will 
be received in-band from the PSTN. 

ii) the available compatibility information will be not exhaustive for deducing a PLMN Basic Service and there will 
be a limitation on address - the terminal may be required to accept the call on the basis of indicating its 
compatibility requirements. 

iii) (if a DTE) in-band handshaking signals should be anticipated. 

9.1.2 Transmission aspects 

Includes control of Speech Processing and Echo Control Devices, see 3GPP TS 43.050. 

9.1 .3 Generation of In-band Tones and Announcements (PLMN-PSTN) 

In-band tones and announcements shall be provided for all speech and 3, 1 kHz audio bearer services between a PLMN 
and a PSTN. 

9.2 Data Calls 

Low Layer Compatibility Checking on the received PLMN bearer capability information element will be carried out by 
the MSC/IWF to check if the call setup is compatible to the bearer service (3,1 kHz audio) provided by a PSTN and to 
the IWFs provided by the PLMN. 

In case the call setup does not conform to these requirements (e.g. an information transfer capability value "unrestricted 
digital information" is requested), the call shall fail with an error cause indicating that the network is unable to support 
the service requested. 

As well as compatibility checking subscription checking shall be performed. If the subscription check fails the call 
setup shall be rejected. 

For the case where the UE offers negotiable values in the PLMN bearer capability information element (e.g. both 
transparent and non-transparent connection element) refer to the definitions specified in 3GPP TS 27.001. 

For interworking of data calls between a PLMN and a PSTN a modem will be utilized to provide the interworking 
function. 
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Figure 1 : PLMN PSTN interworking for circuit switchied calls 



9.2.1 Network interworking mobile originated 



9.2.1.1 



Selection of interworking function 



The interworking function will need to negotiate with the user to establish the appropriate modem selection e.g. data 
rate, modulation scheme, etc. In addition, it will also be required to convert the signalling format, from a combination of 
out of band and in band, to that suitable for controlling the modem and the autocalling line procedure function where 
applicable. It is assumed that the interworking function and modems will be associated with each MSC. 

For a data call originated by a circuit mode data terminal on the PLMN, the modem selection is done by using the 
elements "modem type" and "other modem type" in the bearer capability (PLMN-BC) of the call set-up message. 

In addition, other elements of the call setup will indicate the user rate, etc. to be used via that modem. The use of this 
information however means that the network is only able to select a modem from the modem pool which conforms to 
the speed which the terminal is utilizing at the DTE/DCE interface at the UE (e.g. V.22 for 1 200 bps). The exception to 
this is where the user has selected the non transparent service in which case either an autobauding or multi self selecting 
speed modem (e.g. V.32) may be used. 

If in A/Gb or GERAN lu mode the PLMN-BC(s) received with the set-up message indicated a multislot, 14.4 kbit/s, or 
EDGE-operation (refer to 3GPP TS 27.001) and the network does not support any of the required such services, the 
PLMN-BC(s) sent with the call proceeding message shall not contain the "fixed network user rate", "other modem type" 
and "user initiated modification indicator" parameters - the MSC shall discard the multislot, 14.4 kbit/s and EDGE- 
related parameters and use the fall-back bearer service indicated by the remaining parameters of the PLMN-BS(s) on a 
singleslot configuration (refer to 3GPP TS 48.020 and 3GPP TS 44.021) on the MSC/IWF-RAN link. The MSC/IWF 
shall modify the relevant parameters in a possibly present LLC accordingly. 

If the MSC supports in A/Gb or GERAN lu mode the multislot, 14.4 kbit/s, or EDGE-operation or if the MSC supports 
UTRAN lu mode, the PLMN-BC(s) shall include the "fixed network user rate", "other modem type" and if applicable 
the "user initiated modification indicator" parameters of the call proceeding message if these parameters were present in 
the call set-up message received from the UE. In A/Gb or GERAN lu mode the MSC shall apply on the MSC/IWF- 
RAN link a singleslot or multislot configuration according to the rules defined in 3GPP TS 44.021, 3GPP TS 48.020 
and 3GPP TS 24.022. In case the UE signals an ACC containing TCH/F4.8 only and the network does not support 
TCH/F4.8 channel coding, then the MSC may act as if TCH/F9.6 were included in the ACC. 

If in A/Gb or GERAN lu mode the PLMN-BC(s) received with the set-up message did not indicate a multislot, 14.4 
kbit/s or EDGE-operation, the MSC shall not include the "fixed network user rate", "other modem type" and "user 
initiated modification indicator" parameters in the PLMN-BC(s) of the call proceeding message - the MSC shall use a 
singleslot configuration on the MSC/IWF-RAN link. 

The MSC may negotiate parameters with the UE according to the rules defined in 3GPP TS 27.001. The MSC/IWF 
shall modify the relevant parameters in a possibly present LLC accordingly. 



9.2.1.2 



Modem Selection 



In general terms the indication of the bearer capability parameter "Information Transfer Capability" will be utilized in 
the call set-up message to determine when the modem should be selected in the call. 

In case of single calls, the modem function shall operate in the calUng mode in case of mobile originated calls and in the 
answering mode in case of mobile terminated calls. 

In case of dual data calls (alternate speech/facsimile group 3) the operation mode of the modem (working in calling or 
answering mode) depend on the initial call setup direction and on the optional parameter "Reverse Call Setup Direction" 
information element of the MODIFY message. If this information element is omitted the direction is derived from the 
initial call setup direction, i.e. the mode is the same as in case of single calls. 
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For the attribute value "3,1 kHz audio Ex PLMN" and "facsimile group 3", the modem will be selected immediately. 
The line procedure according to ITU-T Recommendation V.25 will then be carried out using the appropriate modem 
functions. 

For the Teleservice 61 "Alternate speech/facsimile group 3", (if speech is selected as the first service), the modem is 
made available but not selected until the subscriber indicates the change of service request (see subclause 9.3). 

For "alternate speech/facsimile group 3" calls refer to 3GPP TS 43.045 (A/Gb mode) and 3GPP TS 23.146 (UTRAN lu 
mode). 

9.2.1 .3 Mapping of BC-IE from PLMN to ISUP (or other) 

As it cannot be determined from the called address whether the distant network is a PSTN or an ISDN the same 
mapping takes place as for ISDN calls (see table 7A), if ISDN signalling is used between different MSCs (e.g. on the 
link VMSC - GMSC). 

9.2.2 Network Interworking Mobile terminated PSTN Originated 

This subclause describes the interworking of calls where the calling subscriber cannot generate or communicate 
Compatibility Information exhaustive for deducing a PLMN Basic Service to a PLMN (gateway MSC/interrogating 
node) because of lack of ISDN signalling capability. Thus the HLR is relieved from any compatibility checking for such 
calls. 

Two methods of allocating UE International ISDN Numbers (MSISDNs) are allowed: Firstly, a separate MSISDN may 
be allocated for each service, or service option, which a subscriber uses for incoming calls; or, alternatively, a single 
number, applicable for all incoming calls is used. 

It should be noted that it is possible for both schemes to co-exist within the PLMN and that they are not mutually 
exclusive. 

a) Multiple MSISDNs are used ("The Multi-numbering Scheme"). See figure 2. 

b) A single MSISDN is used ("The Single-numbering Scheme"). See figure 3. 

9.2.2.1 Multi-numbering Scheme 

In this scheme, the HPLMN will allocate a number of MSISDNs to a subscriber and associate with each of these 
numbers a Bearer Capability to identify a Bearer or a Teleservice. This Bearer Capability comprises a complete PLMN 
Bearer Capability (PLMN BC) information element with contents according to 3GPP TS 27.001 and coded as per 3GPP 
TS 24.008. In either case, when the HLR receives an interrogation relating to an incoming call (i.e. the MAP "Send 
Routing Information" procedure), it requests a roaming number (MSRN) from the VLR. This request will contain the 
PLMN BC reflecting the service associated with the called MSISDN, i.e. the PLMN BC is passed to the VLR within the 
MAP parameter "GSM Bearer Capability" of the message "Provide Roaming Number". 

If the HLR completes the MAP "Send Routing Information" procedure by providing the MAP "GSM Bearer 
Capability" to the interrogating entity, as specified in sub-clause 10.2.2.3, the GMSC may then map the received PLMN 
BC into the User Service Information field of the lAM message sent to the succeeding node according to the rules 
defined in table 7A. This allows subsequent transit switches to select a codec transparent for data call (e.g. G.711). If 
the GMSC belongs to a Layered Architecture -backbone, it may also use the PLMN BC to select an appropriate codec 
for the call during the BICC codec negotiation (e.g. transparent codec for a data call). 

If the MAP "GSM Bearer Capabihty" is not included in the MAP "Send Routing Information" response, the GMSC 
may use the MAP "Basic Service Code", if received in the MAP "Send Routing Information" response, to determine 
whether the call is a speech or data call. 

At the VMSC, when the incoming call arrives, the PLMN BC associated with the MSRN are retrieved from the VLR 
and sent to the UE at call set-up. 

Where the PLMN specific parameter "connection element" contained in the retrieved PLMN BC-IE, indicates dual 
capabilities then the VMSC shall set it according to its capabilities/preferences. Additionally the parameters correlated 
to "connection element" shall be modified in accordance with 3GPP TS 27.001. 
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The same applies to the parameter modem type if "autobauding type 1" is indicated but the IWF does not support this 
feature. The parameter "data compression" may also be modified according to the capabilities of the IWF. 

Where single capabilities are indicated then the VMSC shall use the requested values if it is able to support the service 
requested. If it is unable to support the requested service then it shall set them according to its capabilities/preferences. 

Where the Compatibility Information is provided in a degree exhaustive to deduce a PLMN Basic Service 

(see application rules in subclause 10.2.2), then the VMSC in providing the PLMN BC IE in the setup message shall set 

the PLMN specific parameters to its capabilities/preferences. 

On receipt of a Set-up message containing the compatibility information, the UE will analyse the contents to decide 
whether the service can be supported (with or without modification, see 3GPP TS 27.001) and the call will be accepted 
or rejected as appropriate. 

The UE may negotiate parameters with the MSC according to the rules defined in 3GPP TS 27.001. If the UE proposes 
to the network to modify the User Rate as well as the correlated parameters Modem Type and Intermediate Rate in the 
call confirmed message or if the UE proposes to the network to modify the Fixed Network User Rate and Other Modem 
Type parameters for multislot, 14.4kbit/s, EDGE and lu Mode operations, the network may accept or release the call 
(see 3GPP TS 27.001). 

This negotiation takes place by means of the UE reflecting back to the MSC a complete bearer capability information 
element in the call confirmed message, with the relevant parameters changed. If this does not take place (i.e. if there is 
no PLMN BC present in the call confirmed message), than the MSC will assume that the values originally transmitted 
to the UE are accepted with the following exceptions: 

• If in A/Gb or GERAN lu mode, the PLMN-BC sent with the set-up message contained the "fixed network user 
rate", "other modem type" and if applicable the "user initiated modification indicator" parameters and no 
multislot, 14.4 kbit/s, and/or EDGE related parameters (refer to 3GPP TS 27.001 and 24.008) are received in the 
PLMN-BC of the call confirmed message or no PLMN-BC is received, the MSC shall discard the "fixed network 
user rate", "other modem type" and "user initiated modification indicator" parameters - the MSC shall use the 
fall-back bearer service indicated by the remaining parameters of the PLMN-BC on a singleslot configuration 
(refer to 3GPP TS 48.020 and 3GPP TS 44.021) on the MSC/IWF-RAN hnk. 

• On the other hand, if in A/Gb or GERAN lu mode the PLMN-BC received with the call confirmed message 
contain(s) multislot, 14.4kbit/s or EDGE-related parameters the MSC shall apply on the MSC/IWF-RAN link a 
singleslot or multislot configuration according to the rules defined in 3GPP TS 44.021, 3GPP TS 48.020 and 
3GPP TS 24.022. In case the UE signals an ACC containing TCH/F4.8 only and the network does not support 
TCH/F4.8 channel coding, then the MSC may act as if TCH/F9.6 were included in the ACC. 

• If in UTRAN lu mode the PLMN-BC sent with the set-up message contained the "fixed network user rate", 
"other modem type" and if applicable the "user initiated modification indicator" parameters, but no related 
parameters (refer to 3GPP TS 27.001 and 24.008) are received in the PLMN-BC of the call confirmed message 
or no PLMN-BC is received, the MSC shall release the call. 

The VMSC may map the received PLMN BC into an ISDN BC according to the rules defined in table 7A. This ISDN 
BC can be transported together with possibly available LLC and HLC in the access transport parameter of the Answer 
message (ANM) according to ITU-T Q.763. 
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NOTES: (1 ) The HLR translates the received MSISDN_ called address (IVISISDNk) into the relevant bearer 
capability information (BCk). 

(2) Some parameters of BCk may be provided/modified according to the MSC's capabilities/preferences. 
See subclause 9.2.2. 

(3) In the "Call Confirmed" message, the UE may modify some parameters of the BC. See subclause 
9.2.2. 

(4) The VIVISC may map the PLMN BC (BC"k) into an ISDN BC (BC""k) according to the rules defined in 
table 7A. 

Abbr.: SRI - Send Routing Information. 

PRN - Provide Roaming Number. 

I\/1SRN - Mobile Station Roaming Number. 

lAM - Initial Address Message. 

SIFICSU - Send Information For Incoming Call Set Up. 
ANM- Answer Message 

Figure 2: Call Flow for a mobile terminated, PSTN originated call 

where the compatibility information provided are not exhaustive for deducing a PLMN Bearer 

Service; HLR uses multiple MSISDN numbers with corresponding BCs 



9.2.2.2 



Single-numbering Scheme 



In the single-numbering scheme, the HPLMN will allocate one MSISDN to a subscriber, applicable to all services. 

In this case, when the HLR receives an interrogation relating to an incoming call without compatibility information 
exhaustive for deducing a PLMN Basic Service (i.e. the MAP "Send Routing Information" procedure), the request to 
the VLR for a roaming number will not contain compatibility information i.e. a PLMN BC. 

At the VLR, when the incoming call arrives, there is no PLMN BC associated with the MSRN and so the call set-up to 
the UE will not contain the PLMN BC information element. However, the VMSC may include all available information 
in the BACKUP BC information element of the call set-up message, see subclause 10.2.2.7. 
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In the case the PLMN was not able to provide a PLMN BC, the UE will return a complete single or dual PLMN BC in 
the Call Confirmed message, indicating the service required by the mobile subscriber. The VMSC will analyse this 
PLMN BC and optionally perform subscription checking (see 3GPP TS 22.001). If the requested PLMN BC can be 
supported the call is established, otherwise the call will be released. 

The VMSC may map the received PLMN BC into an ISDN BC according to the rules defined in table 7A. This ISDN 
BC can be transported together with possibly available LLC and HLC in the access transport parameter of the Answer 
message (ANM) according to ITU-T Q.763. 
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NOTE: (1) This BC is derived from information stored in the UE, according to its configuration. The UE may also 
use the information provided in the Backup BC. 

(2) The Backup BC may be included if the BC is missing. 

(3) The VIVISC may map the PLMN BC (BC) into an ISDN BC (BC") according to the rules defined in table 
7A 

(4) Abbreviations: see figure 2. 

Figure 3: Call Flow for a mobile terminated, PSTN originated call 

where the compatibility information provided are not exhaustive for deducing a PLMN Bearer 

Service; HLR uses single MSISDN numbers (no corresponding BC stored). Per call MSRN allocation 

9.2.3 Transparent service support 

The protocol stacks for transparent services are specified in 3GPP TS 43.010 and in Clause 1 la. 3. 

In lu mode, the transparent services are based in the lu User Plane protocol specified in 3GPP TS 25.415. 

In A/Gb mode the rate adaptation scheme shall be utilized on the RAN to MSC link as identified in 3GPP TS 48.020. 
The transcoding function will generate the 64 kbit/s rate adapted format utilizing the 8 and 16 kbit/s intermediate data 
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rates. The MSC to MSC/IWF link (e.g. in the case of handover) will utilize the same 64 kbit/s rate adaptation scheme as 
that indicated in 3GPP TS 48.020. 

For the transparent service support the MSC/IWF will select the modem and speed based on the Compatibility 
information contained in either the call set-up or call confirmed message reference subclauses 9.2.1 and 9.2.2. Where 
the modem type indicated is one of the multi-speed versions, e.g. V.32, then the MSC/IWF will restrict the modem to 
the speed indicated in the call set-up and call confirmed message, respectively, i.e. will inhibit the modem from 
changing speed, irrespective of the conditions, error rate, encountered on the PSTN link. This scenario is also applicable 
for the use of "autobauding" modems, in that only the specifically requested modem type and speed will be selected at 
the MSC/IWF (however Facsimile Group 3 can use channel mode modify). 

9.2.3.1 Structure of the MSC/IWF for lu mode 

The transmission towards the RNC is based on AAL2. The lu UP is used in the transparent mode. 



lu UP 



AAL2 



ATM 



MODEM 



Figure 4: Structure of MSC/IWF 



9.2.3.2 



Structure of the MSC/IWF for A/Gb mode 



The rate adaptation process is a reverse of that provided in the Terminal Adaptation function of the UE. The rate 
adaptation RAl is based on the ITU-T Recommendation V.l 10 80 bit frame for TCH/F2.4, TCH/F4.8 and TCH/F9.6 
and on A-TRAU frame for TCH/F14.4. 3GPP TS 44.021 and 3GPP TS 48.020, respectively, refer to the rate adaptation 
mechanisms to be provided. For multislot configurations refer to 3GPP TS 43.010. 

NOTE: From MSC/IWF's perspective a TCH/F28.8 EDGE configuration is identical to a multislot 2xTCH/F14.4 
configuration. 
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Figure 5: Rate adaptation schematic 

In case of asynchronous bearer services and the facsimile teleservices in the transparent mode, the IWF shall disregard 
the value of bits E4, E5, E6 and E7 in the data transmission phase. 



9.2.3.3 



Mapping of signalling UE/MSC/IWF to modem interface requirements 



This process also is a reverse of the function provided in the Terminal Adaptation function of the UE for the mapping of 
DTE/DCE signalling information to Dm channel and in band signalling information. See 3GPP TS 27.002 and 3GPP 
TS 27.003. 
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Figure 6: Signalling mapping schematic 

Status bits SA, SB and X can be used to convey channel control information associated with the data bits in the data 
transfer state. Table 5 shows the mapping scheme between the V.24 circuit numbers corresponding to the V-series DCE 
functions and the status bits for the transparent mode. It also shows how the unused status bits should be handled. It is 
derived from the General Mapping scheme described in annex B. A binary corresponds to the ON condition, a binary 
1 to the OFF condition. 

The transport of these status bits by the various channel codings is described in 3GPP TS 44.021 and 3GPP TS 48.020 
for A/Gb mode. For lu mode refer to Clause 11a. 

NOTE Although the interface to the modem is described in terms of V.24 interchange circuit functions, this does 
not imply that such circuits need to be physically realised. 

Table 5: Mapping scheme at the IWF for the transparent mode 



Mapping 
direction: UE to IWF 


IVIapping 
direction: IWF to UE 


Signal at IWF modem 

interface or condition 

within the IWF 


always ON (note 1 ) 




CT105 




to status bit X 


CT106 




not mapped (note 5) 


CT107 


not mapped (note 6) 




CT108 




to status bit SB 


CT109 


always ON (note 2) 




CT133 


from status bit SA (note 3) 




ignored by IWF 


from status bit SB (note 1 ) 




ignored by IWF 


from status bit X (note 4) 




ignored by IWF 




to status bit SA (note 3) 


always ON 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (annex B), 
could be used to carry CT 1 05 from the mobile DTE to the modem in the 
IWF. However, CT 105 should always be ON at the DTE interface in the 
data transfer state since only duplex operation is supported. Also, many 
DTEs use the connector pin assigned to CT 105 for CT 133. Therefore, 
CT 105 shall always be set to ON at the IWF modem during the data 
transfer state. 

NOTE 2: CT 133 is not mapped since there is no flow control in transparent mode. 

NOTE 3: The SA bits in both directions are available only with certain channel 
codings. Therefore, for maximum compatibility, they should not be 
mapped. 

NOTE 4: The X bit towards the IWF is not mapped since there is no flow control in 
transparent mode. 

NOTE 5: CT 1 07 is not used by the IWF. 

NOTE 6: CT 108 is used in the call setup and answering processes. 



In general it is not required for the modem in the MSC/IWF to support a "remote looping" request from a modem in the 
PSTN. In addition the invocation of a "remote looping" request from the mobile subscriber to a modem in the PSTN 
need not be supported (see also 3GPP TS 27.001). Specific test loops for mobile subscribers to contact may be provided 
at the network operators discretion. 



9.2.3.4 



Establishment of end-to-end terminal synchronizations 



Prior to exposing the traffic channel of a PLMN connection to transmission of user data, the controlling entities of the 
connection shall assure of the availability of the traffic channel. This is done by a so called synchronizations process: 
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starting on the indication of "physical connection established" resulting from the PLMN-inherent outband 
signalling procedure. This indication is given: 

- for MOC: on sending the CONNECT message; 

- for MTC: on sending the CONNECT ACKNOWLEDGE message; 

for mobile initiated in-call modification: on sending the MODIFY COMPLETE message (which is sent after 
reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message); and 

- for network initiated in-call modification: on reception of the ASSIGNMENT COMPLETE or RAB 
ASSIGNMENT RESPONSE message; 

ending by indicating the successful execution of this process to the controlling entity, which then takes care of 
the further use of the inband information (data, status). 

Network interworking within an MSC/IWF is concerned with the terminating side (to the UE) and the transit side (to 
the fixed network) of a connection. Both sides have to be treated individually related to the synchronizations process. 

9.2.3.4.1 Terminating side (towards the UE) 

9.2.3.4.1 .1 Traffic channel types TCH/F4.8 and TCH/F9.6 for A/Gb mode 
With respect to the terminating side the procedure is as follows: 

- sending of synchronizations pattern 1/OFF (all data bits" 1 "/all status bits "OFF") to the UE using the RAI/RA2 
rate adaptation function. In multislot transparent operation, the synchronisation pattern sent is 1/OFF with the 
exception of the bit positions SI, first X, S3, and S4 which contain the substream number and multiframe 
alignment pattern (see 3GPP TS 44.021); 

searching for detection of the synchronizations pattern from the UE within valid V. 110 frames, and in multislot 
operation, also searching for the multiframe ahgnment pattern "0000 1001 01 10 01 1 1 1 100 01 10 1 1 10 101" (see 
3GPP TS 44.021) in bit position S4 and substream numbers in bit positions SI, first X, and S3. This implies that 
the El , E2 and E3 bit of the V. 1 10 frame shall be checked for the appropriate user rate in order to distinguish the 
synchronization pattern from the RAN idle data frame; 

timer T (= 500 ms) is started for each of the allocated traffic channel(s) of the call on receipt of the 
synchronizations pattern from the UE; 

when the frame alignment pattern and, in case of multislot operation, the multiframe alignment pattern have been 
recognized as a steady state, the MSC/IWF continues sending the synchronizations patterns to the UE until a 
timer T expires. 

9.2.3.4.1 .2 Traffic channel type TCH/F14.4 for A/Gb mode 

With respect to the terminating side the procedure is as follows: 

sending A-TRAU frames with the data rate set in the bits C1-C4 (TS 48.020) and data bits set to one, sending the 
multiframe structure with the alignment pattern (bit Ml) and with the status bits OFF (bit M2) and, in a multislot 
case, sending substream numbers (bit M2); 

- searching for the detection of the multiframe ahgnment pattern "0000 1001 01 10 01 1 1 1 100 01 10 1 1 10 101 " 
(TS 44.021) in the bit Ml and, in a multislot case, searching for substream numbers in the bit M2. (Any 5 bit 
sequence in the multiframe alignment pattern is unique, i.e. the multiframe alignment can take place by 
recognition of five successive Ml bits); 

timer T (= 500 ms) is started for each of the allocated traffic channel(s) of the call on receipt of the 
synchronizations pattern from the UE; 

when the frame alignment pattern and the multiframe alignment pattern have been recognized as a steady state, 
the MSC/IWF continues sending the synchronizations patterns to the UE until a timer T expires. 
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9.2.3.4.1.3 User Plane for lu mode 

The IWF does not send any frame down link until the modem connection has been established and the modems have 
synchronised. Thereafter the IWF through connects, mapping data from the fixed network side onto frames that are sent 
toward the UE, and mapping data in the received frames to the fixed network side. 

9.2.3.4.2 Transit side (towards the fixed network) 

With respect to the transit side the procedure is as follows: 

at the start of timer T for each of the allocated traffic channel(s) of the call, circuit 108 to the selected modem 
associated with the connection will be switched from the "OFF" to "ON" condition, thus initiating the 
establishment of the modem connection. In the case of mobile originated calls, this initiates the auto calling 
sequence and after signalling, calling tone according to V.25 shall be generated by the modem in the IWF; 

the interchange circuits towards the modem (with the exception of CT108) are held in the OFF condition until 
timer T expires, when they are switched to ON; 

from this time, after the expiration of the timer T of every allocated traffic channel, the information on CT106 
and CT109 from the IWF Modem are directly mapped to the SB and X bits toward the UE. For TCH/F14.4 the 
SB and X bits are mapped to the M2 multiframe bits according to 3GPP TS 44.021. The IWF is allowed to map 
CT104 to the data bits sent towards the UE and to map data bits received from the UE to CT103. 

9.2.3.5 Network Independent Clocking (NIC) 

The network independent clocking function applies only to A/Gb mode. It is invoked by the VMSC/IWF when the 
service requested (MO or MT) is 3,1 kHz Ex PLMN and synchronous. The above rule applies irrespective of the 
information contained in the 3GPP TS 24.008 setup message regarding NIC. For all other services NIC is not used. 

Within the PLMN the coding of the values for bits associated with NIC is specified in 3GPP TS 44.021 and 3GPP TS 
48.020. In the forward (transmitting) direction the multiframes shall be coded in exact accordance with that specified in 
those specifications. Bit E6 is set to "1" in alternate modified V.llO frames at the transmitter. However, the use of this 
bit at the receiver for monitoring frame synchronization, or any other purpose, is not specified and is left to the 
discretion of the implementer. 

A "perfect linear block Code" is used in C1-C5, whose error correction properties may be utilized in the receiver, in 
order to ensure reliable operation of NIC. 

The NIC sending function shall recognize when the difference between the applicable clock speed of the PLMN and the 
interface speed generates a positive or negative whole bit requirement. When this positive or negative condition occurs, 
the NIC codewords specified in 3GPP TS 44.021 are used to transport this condition to the receiving NIC function. 
Transmission of the codeword shall clear the positive or negative condition related to that codeword at the sending 
function. The sending function shall not send more than one positive or negative compensation within a contiguous 
period of time corresponding to 10 000 user data bits minus the maximum NIC code framing delay (e.g. in the case of 
TCH/F2.4, TCH/F4.8 or TCH/F9.6, the number of user data bits necessary to make up an even number of V. 1 10 frames 
between compensation). NIC compensation is coded in two V.llO frames in the case of TCH/F2.4, TCH/F4.8 or 
TCH/F9.6 and in one multiframe in the case of TCH/F14.4. This results from the requirements to compensate for 
maximum clock differences of +100 parts per million. If the receiving function receives NIC compensations in the 
average more often than a contiguous period of time corresponding to 10000 user data bits, there is no guarantee that 
data will not be lost. 

The NIC receiving function shall provide the capability to support the compensation requirements of the sending 
function. This compensation is managed by manipulating the clock speed of the interface, within the standard 
constraints of that interface. 

Overall, the compensation functions shall be capable of managing clock tolerances of +100 parts per million. 

Action on loss of synchronization. 

If five consecutive NIC multiframes in the V.llO frame have incorrect framing bit values in E7 or if the A-TRAU 
multiframe synchronisation is lost, the receiver shall stop applying clocking compensation to the received data. 
Resynchronization will be attempted and compensation will resume when synchronization is achieved. 
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9.2.4 Non-transparent service support 



The protocol stacks for non-transparent services are specified in 3GPP TS 43.010 and in Clause 1 la. 2. Both of the 
systems use the Radio Link Protocol (RLP) specified in 3GPP TS 24.022. 

In lu mode, the non-transparent services are based in the lu User Plane protocol specified in 3GPP TS 25.415. 

In A/Gb mode the corresponding necessary support concerning the rate adaptation scheme shall be utilized on the 
RAN-MSC link as identified in 3GPP TS 48.020. 

For the non-transparent service support the MSC/IWF will select the modem and speed based on the Compatibility 
information contained in either the call set-up or call confirmed message, reference subclauses 9.2.1 and 9.2.2. Where 
the Modem Type indicated is autobauding type 1, the MSC/IWF may select any speed and modem type according to 
what it can negotiate with the remote modem. In this case User Rate and Fixed Network User Rate, if present, has no 
meaning. 



9.2.4.1 



Structure of the MSC/IWF for lu mode 



The transmission towards the RNC is based on AAL2. The lu UP is used in the support mode. The RLP/L2R extends to 
the UE. 
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Figure 7: Structure of MSC/IWF 



9.2.4.2 



Structure of the MSC/IWF for A/Gb mode 



The rate adaptation process will be the same as for the transparent case (see figure 5), except that a TCH/F43.2 channel 
coding is also supported. From MSC/IWF's perspective a TCH/F43.2 EDGE configuration is identical to a multislot 
3XTCH/F14.4 configuration. 

3GPP TS 43.010 identifies the protocol layer structures for the non-transparent case, the physical layer to the PSTN is 
provided by means of a modem. 



9.2.4.3 



Re-constitution of user data 



3GPP TS 24.022 refers to the frame of user data in the radio link protocol. The layer 2 relay functions in the UE and the 
MSC/IWF (identified in 3GPP TS 43.010) contain the mechanism for packing and unpacking the user data into the L2R 
protocol data units. 



9.2.4.4 



Layer 2 relay functionality 



Specific functionality is required of the L2R dependant upon the service which is being requested to be supported. The 
selection of the appropriate L2R function will be determined by the MSC/IWF on the basis of the bearer capability 
information signalled in either the call set-up request, or call confirmation messages. The prime information element 
being transparent or non transparent service indication. In addition the particular L2R function will be selected on the 
basis of the users layer 2 indication - type of protocol to be terminated and mode of flow control to be applied 
(see appropriate clauses of the 3GPP TS 27 series). 

The specific interaction between the L2R function and the RLP function and the L2R frame structure will be the same 
as that detailed in the annex to the appropriate 3GPP TS 27 series. 
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9.2.4.5 In band signalling mapping flow control 

This entails the L2R function providing the means of controlling and responding to flow control functions of the 
modem plus any synchronization requirements related to flow control. For asynchronous services a specific rule applies 
for flow control (see 3GPP TS 27.001). 

The flow control function chosen will be dependent upon the information contained or not contained in the "user 
information layer 2" information element of the PLMN BC received from the UE. 

If flow control is provided, irrespective of the type used the L2R function shall: 

(a) provide immediate indication of flow control to the fixed network on receipt of flow control request from the 
UE; and/or 

(b) provide immediate indication of flow control to the UE on receipt of flow control request from the fixed network 
i.e. in the next available L2R status octet to be transmitted. 

Where in-band (X-on/X-off) flow control is in use, then the X-on/X-off characters will not be passed across the radio 
interface. 

For outband flow control refer to subclause 9.2.4.9. 

If no flow control is provided, the involved end systems are responsible for performing in-band flow control on their 
own by taking into account the buffer capacity of the MSC/IWF stated below. 

9.2.4.5.1 Conditions requiring flow control towards the fixed network 

The L2R function will initiate flow control - if flow control is present - in the following circumstances: 

1) the transmit buffer reaches a preset threshold (BACK PRESSURE); 

2) the L2R function receives an explicit "flow control active" indication. 

No flow control initiation/removal will take place at the L2R function and loss of data may occur if no flow control is 
provided. 

On removal of buffer congestion or receipt of L2R "flow control inactive" the flow control will be removed. 

9.2.4.5.2 Conditions requiring flow control towards the UE 

The L2R function will transmit to the UE an explicit "flow control active indication" if flow control is provided in the 
following circumstances: 

1) if the receive buffer from the radio side reaches a preset threshold (BACK PRESSURE); 

2) if a flow control indication is received from the fixed network customer. On receipt of this flow control 
indication, transmission of data from the receive buffers towards the fixed network terminal is halted. 

On removal of the buffer congestion or fixed network flow control indication, the L2R function will send a "flow 
control inactive" indication towards the UE. In addition, for the fixed network indication, transmission of data from the 
receive buffers will be restarted. 

If no flow control is provided at the L2R function, no flow control initiation/removal will take place by the MSC/IWF. 
Data might be lost without any indication by the MSC/IWF to the end systems involved. 

9.2.4.6 Data buffers 

9.2.4.6.1 Transmit buffers (towards UE) 

Incoming data from the fixed network customer shall be buffered such that if the MSC/IWF is unable to transfer data 
over the radio path the data is not lost. 

The buffer shall be capable of holding the data. Its size is up to the implementers. When the buffer is half full flow 
control towards the fixed network shall be initiated if flow control is provided as per subclause 9.2.4.5.1. 
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9.2.4.6.2 



Receive buffers (from UE) 



Incoming data from the UE is buffered such that if the fixed network terminal is unable to accept the data then it is not 
lost. 

The buffer shall be capable of holding the data. Its size is up to the implementers. When the buffer becomes half full, 
the L2R function will send a "flow control active" indication towards the UE if flow control is provided at the L2R 
function, as per subclause 9.2.4.5.2. 



9.2.4.7 



Transportation of the Break condition 



The "BREAK" condition shall be recognized by the L2R function and passed immediately to the UE. The L2R will 
generate a "BREAK" condition towards the fixed network on receipt of a break indication from the MS. The action of 
the "BREAK" on the L2R transmit and receive and the length of the "BREAK" signal to be generated towards the fixed 
network is described in 3GPP TS 27.002. 



9.2.4.8 



In band signalling mapping modem status information 



Status information is carried between the modem in the IWF and the terminal adaptation function in the UE by the L2R 
function. The L2RCOP entity transfers interface status information between L2Rs via the status octets SA, SB and X in 
L2RCOP-PDUs (3GPP TS 27.002). Table 6 shows the mapping scheme between the V.24 circuit numbers 
corresponding to the V-series DCE functions and the status bits for the non-transparent mode. It also shows how the 
unused status bits should be handled. It is derived from the general mapping scheme described in annex B. A binary 
corresponds to the ON condition, a binary 1 to the OFF condition. 

NOTE: Although the interface to the modem is described in terms of V.24 interchange circuit functions, this does 
not imply that such circuits need to be physically realised. 

Table 6: Mapping scheme at the IWF for the non-transparent mode 



Mapping 
direction: UEtolWF 


Mapping 
direction: IWF to UE 


Signal at IWF modem 

interface or condition within 

the IWF 


always ON (note 1 ) 




CT105 




to status bit X (notes 4, 7) 


CT 106 (note 7) 




not mapped (note 5) 


CT107 


not mapped (note 6) 




CT108 




to status bit SB 


CT109 


from status bit X (note 8) 




CT 133 (notes 3, 8) 


from status bit SA (note 2) 




ignored by IWF 


from status bit SB (note 1) 




ignored by IWF 




to status bit SA (note 2) 


always ON 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (annex B), could be 
used to carry CT 105 from the mobile DTE to the modem in the IWF. However, CT 
105 should always be ON at the DTE interface in the data transfer state since only 
duplex operation is supported. Also, many DTEs use the connector pin assigned to 
CT 105 for CT 133. Therefore, CT 105 shall always be set to ON at the IWF modem 
during the data transfer state. 

NOTE 2: The SA bits (both directions) are not mapped since CTs 107 and 108 are handled 
locally (notes 5 and 6). 

NOTE 3: The condition of CT 133 (or other flow control mechanism) may also be affected by 
the state of the L2R transmit buffer (towards the UE) in the IWF and the state of RLP 
(RR/RNR). 

NOTE 4: The condition of status bit X towards the UE may also be affected by the state of the 
L2R receive buffer (from the UE) in the IWF. 

NOTE 5: CT 1 07 is not used by the IWF. 

NOTE 6: CT 108 is used in the call setup and answering processes. 

NOTE 7: For inband flow control, CT 1 06 is not mapped and the status bit X towards the UE is 
controlled by the reception of XON and XOFF characters from the modem. 

NOTE 8: For inband flow control, changes in the condition of the status bit X from the UE 
result in the sending of XON or XOFF to the modem. CT 133 is always set to ON. 
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9.2.4.9 Support of out-band flow control 

Out-band flow control in case of the asynchronous bearer service requires V.42 functionality in the modems in the 
MSC/IWF and the fixed network. 

If this functionality is requested by the UE but cannot be provided by the MSC/IWF or the remote (fixed network) 
modem for any reason, the call shall be supported without V.42 functionality (fall back to the non-error correction mode 
according to ITU-T Recommendation V.42). 

This implies that no flow control initiation/removal (refer to subclause 9.2.4.5.1) is possible towards the fixed network. 
In this case the L2R transmit buffers in the IWF (towards the UE, refer to subclause 9.2.4.6.1) shall overbridge 
temporary throughput problems on the radio interface and the case where the UE initiates flow control. The IWF 
however shall release the connection if an overflow of these buffers occurs. 

9.2.4.1 Establishment of end-to-end terminal synchronizations 

Prior to exposing the traffic channel of a PLMN connection to transmission of user data, the controlling entities of the 
connection shall assure of the availability of the traffic channel. This is done by a so called synchronization process: 

starting on the indication of "physical connection established" resulting from the PLMN -inherent outband 
signalling procedure. This indication is given: 

- for MOC: on sending the CONNECT message; 

- for MTC: on sending the CONNECT ACKNOWLEDGE message; 

for mobile initiated in-call modification: on sending the MODIFY COMPLETE message (which is sent after 
reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message); and 

- for network initiated in-call modification: on reception of the ASSIGNMENT COMPLETE or RAB 
ASSIGNMENT RESPONSE message; 

ending by indicating the successful execution of this process to the controlling entity, which then takes care of 
the further use of the in-band information (data, status). 

Network interworking within an MSC/IWF is concerned with the terminating side (to the UE) and the transit side 
(to the fixed network) of a connection. Both sides shall be treated individually related to the synchronization process. 

9.2.4.1 0.1 Terminating side (towards the UE) 

With respect to the terminating side the procedure in A/Gb mode is as follows: 

reception of V.llO or A-TRAU frames on all allocated traffic channels for the call is required before the 
MSC/IWF shall reply with an RLP-UA frame to the MT's RLP link establishment request (if the MSC/IWF 
initiates the RLP link establishment, reception of V.llO frames or A-TRAU on all allocated traffic channels for 
the call shall be detected first); 

waiting for the RLP link establishment by the MT (in addition the MSC/IWF may initiate the RLP 
establishment). 

In lu mode at the IWF, the synchronisation of modems on the transit network is performed after establishment of the 
physical connection. The RLP establishment may be initiated by the IWF, but is normally initiated by the UE. If the 
modems synchronise before the RLP has been established, the IWF stores the information received from the other 
modem in the L2R buffers. 

9.2.4.1 0.2 Transit side (towards the fixed network) 

Depending upon implementation - CT108 will be turned ON to enable the autocalling/autoanswering function of the 
selected modem either when the RLP has been established or in parallel to RLP establishment. If CT 108 is turned ON 
in parallel to the RLP establishment, the modem connection may be established before the RLP is established. In this 
case, data received from the transit side during RLP establishment shall be stored within the L2R buffers until the RLP 
establishment at the terminating side has been finished. When the RLP has been established, the information from/to the 
RLP including status changes will be mapped by the L2R entity applicable to the particular bearer capability. After 
signalling, for MO calls, calling tone according to V.25 shall be generated by the modem in the IWF. 
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9.2.4.1 1 Data compression 

When data compression is invoked within a non-transparent bearer service, interworking to the fixed network is realized 
as follows. 

The PLMN BC is used to indicate the interworking modem type and user rate. The modems shall try to negotiate data 
compression and flow control. If negotiation of data compression fails in the fixed network, the call continues with data 
compression between UE and IWF only. 

9.2.4.12 Service level up and down grading 

Service level up and down grading is only applicable for A/Gb mode and GERAN lu mode. If the value of the RLP 
parameter "UP signalling" is negotiated to 1, the IWF shall send a suggestion to the UE to initiate an upgrading 
whenever the following condition holds: 

The IWF: 

1) is receiving user data from the fixed network side at a higher rate than the current AIUR; or 

2) in symmetrical calls only, can send user data towards the fixed network side at a higher rate than the current 
AIUR. 

When the above condition does not hold, the IWF sets the value of the UP bit continuously to 0. When the condition 
above does hold, the IWF indicates the number of traffic channels to upgrade by, by sending that number of Is between 
two consecutive Os in the UP bit sequence. This indication is not repeated since the FCS protects it. For instance, if the 
current number of traffic channels is two and an upgrading to four traffic channels is suggested, the UP bit sequence 
shall be ..01 100... How the IWF detects the condition and additional details for setting and resetting of the UP bit, 
e.g., hysteresis levels, may depend on implementation. 

NOTE: From MSC/IWF's perspective a TCH/F28.8 or TCH/F43.2 EDGE configuration is identical to a multislot 
2xTCH/F14.4 or 3xTCH/F14.4 configuration. In this case, rather than suggesting the number of channels 
to add, the IWF suggests a number of 14.4 substreams to add and therefore a factor of 1/2 or 1/3 shall be 
applied to the suggested increase when the assigned up link channel is TCH/F28.8 or TCH/F43.2 
respectively. 

9.2.5 DTE/DCE interface (Filtering) 

The DTEs taken into account for the PLMN at the UE side conform to ITU-T's DTE/DCE interface specifications, 
which assume basically an error-free environment, i.e.: 

limited distance, point-to-point local interconnection of the interface circuits for data and status; 

steady state signalling. 

The envisaged use of these DTE's in the PLMN environment leads to the exposure of these "interconnections" - which 
may, in the ISDN case, lead to the ISDN Rate Adaptation rather than to a Modem in the MSC/IWF - to the PLMN 
Radio Channel. To assure proper operation even under these conditions appropriate measures shall be taken. In the 
"non-transparent case" the RLP satisfies the requirement for both data and status lines. In the "transparent" case, the: 

data line aspects shall be dealt with end-to-end between the users; while 

status line aspects are of concern to the network which are dealt with in the following. 

The use of the channel control information for the remote control of the DTE/DCE control interchange-circuits between 
the UE and the MSC/IWF (the conveyance of which is supported by the rate adaptation scheme adopted for PLMN 
application) requires alignment to the particular transmission occurrences in the traffic channel to be taken into account 
within the PLMN. In principle this can be best achieved by: 

relying only on the PLMN outband signalling as far as connection control is concerned; 

eliminating the dependence upon the transmission of channel control information via the radio link. 

Support for this strategy is given to a certain extent by the confinement of PLMN data connections to: 
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full duplex operation (no turning round of the connection is required); 

switched service (demand access); 

mapping of connection-control relevant conditions of the DTE/DCE control interchange-circuits to/from outband 
PLMN signalling according to 3GPP TS 24.008 after successful traffic channel synchronization; 

flow control by a network entity supported only in non- transparent mode; 

support of connections with the same user data rate only (no TA to TA end-to-end flow control in case of 
transparent mode). 

The only DTE/DCE control interchange-circuit conditions, which actually are not covered by the above confinements, 
are the indications of readiness for data transmission, i.e. CT106/109 in case of V. -series interface and I-circuit of 
X. -series interface. As the effect of a condition change of the afore-mentioned DTE/DCE interchange-circuits depends 
on the: 

phase within the course of the connection; 

- direction of change (ON-OFF or OFF-ON) . 

The required precaution to be applied (Filtering) shall be determined individually in view of: 

function deduced from the change; 

resilience of the connection needed; 

error condition possibly invoked due to a delay in performing the condition change of the control interchange 
circuit; 

potential loss of performance in connection usage. 

The details of the filtering function are laid down in 3GPP TS 27- series. Filtering of channel control information is 
only relevant at the UE side in the transparent mode of operation. 

9.3 Interworking Alternate Speech / Facsimile Group 3 Calls 
9.3.1 General 

The procedure for the alternate speech/facsimile group 3 services is invoked at UE-MSC link during the call set-up 
phase. This service is invoked by indication of repeated bearer capability information elements in the setup message 
and/or call confirmed message respectively (preceded by a repeat indicator "circular"), one indicating speech and the 
other indicating facsimile group 3. The facsimile service requested will be indicated by the information transfer 
capability "facsimile group 3", as for a normal single call. The bearer capability first indicated i.e. speech or facsimile 
group 3 determines the first selection required of the network by the subscriber. Depending on the type of service 
requested and direction of call establishment (MO/MT, see relevant clauses of 3GPP TS 27 series) low layer and high 
layer capabilities may also be included. The MSC/IWF will perform both compatibility checking and subscription 
checking on both sets of capabilities as for normal data calls. If either the subscription check or the compatibility check 
fails then the call will be rejected. The only exception to this is when TS61/TS62 negotiation takes place, see 3GPP TS 
27.001. 

The applicable rules for provision of supplementary services are laid down in 3GPP TS 22.004. 

The "speech" phase of the call, when invoked is handled by the transcoder and will utilize normal telephony teleservice 
interworking requirements and mobile network capabilities. This includes any requirements for echo cancellers etc. as 
indicated in subclause 9.1. The "facsimile group 3" phase of the call, when invoked, shall utilize the appropriate data 
interworking capability (IWF including modem) and shall use the transparent mobile network capability in A/Gb mode 
or the non-transparent mobile network capability in UTRAN lu mode. 

The network shall provide, for service and operational reasons, a rapid and reliable changeover of capability upon 
request from the mobile user. This changeover may involve the disabling, by-passing or introduction of particular 
network functions (e.g. speech coder, modem etc.) and change of the channel configuration on the radio interface. This 
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changeover is initiated on the receipt of the "MODIFY" message (see 3GPP TS 24.008) from the UE. The network 
itself will not initiate a changeover. 

9.3.2 Mobile originated PSTN terminated calls 

The call is set up in the normal manner (but with repeated bearer capability information elements as described in 
subclause 9.3.1 and handled by the MSC/IWF as indicated in the general clause. 

9.3.3 PSTN originated mobile terminated calls 

The call set up request for this particular service is performed in a similar manner to that indicated in subclause 9.2 for 
normal PSTN originated calls. 

When multiple MSISDNs are used by the HLR ("Multi-numbering scheme"), one PLMN BC-IE with the ITC value set 
to "alternate speech/facsimile group 3, starting with speech" is passed to the VLR in the MAP operation "provide 
roaming number". The VLR stores this information against the MSRN. 

When the call arrives at the visited MSC this information is retrieved from the VLR and sent to the UE in the setup 
message as defined in 3GPP TS 27.00L 

If the ITC of the PLMN BC-IE retrieved from the VLR has the value "alternate speech/facsimile group 3, starting with 
speech" this PLMN BC-IE shall be mapped to two PLMN BC-IEs (preceded by a repeat indicator "circular"), one 
representing speech, the other representing facsimile group 3. The order in which these two PLMN BC-IEs are sent 
towards the UE, in the setup message, is a network option. 

In order to allow auto answering mode for the facsimile phase (i.e. the call starts automatically with the facsimile 
phase), the UE can reflect back to MSC the dual Bearer Capability in the Call Confirm message with the BC elements 
interchanged to those in the original Call Set-up message (i.e. facsimile element first or negotiate to facsimile only, see 
subclause 9.2.2 and 3GPP TS 27.001). In all other aspects it is handled as indicated for mobile originated. 

NOTE: However, the PLMN specific parameters "connection element" and "radio channel requirements" of the 
retrieved PLMN BC-IE may be modified, or added in line with the principles identified in 
subclause 9.2.2. 

When a single MSISDN is allocated to the subscriber ("single numbering scheme"), the call is handled as described in 
case b) of subclause 9.2.2. In the "call confirmed" message, however, two PLMN BC-IEs are preceded by a repeat 
indicator "circular", with the first PLMN BC-IE indicating the initial phase of the connection. 

9.3.4 BICC network architecture 

In a BICC network architecture the following procedures apply for both mobile originated and mobile terminated 
alternate speech/facsimile group 3 calls: 

The PLMN BC-IE value of ITC equal to 'alternate speech/facsimile group 3, starting with speech' shall not be used in 
the H.248 signalling towards the MGW. Instead, the MGW terminations shall be configured for the speech portion of 
the call using the Acodec property. 

To switch to fax mode, the PLMNBC property with ITC indicating "facsimile group 3" shall be applied on appropriate 
terminations, as detailed in Clause 11 a. 1.3, to insert the MGW IWF and configure the fax call. Usual procedures to 
setup a CSD call is followed as described TS 29.232 [82]. 

Similarly, to switch from fax to speech mode, the PLMNBC property shall be removed and the terminations shall be re- 
configured for the speech portion of the call using the Acodec property. 

9.4 3G-H.324/M calls over 3,1 kHz audio 

In case of 3G-H.324/M calls over 3. IkHz audio, the IWF shall provide the V.34 modem modulation and the V.8 
procedure with the indication of H. 324 support in the call function category of the V.8 handshaking. H.223 and H.245 
flow is not terminated in the modem function. 

The performance of V.8bis by the modem function is FFS. 
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9.4.1 Mobile originated multimedia call 

9.4.1.1 Call setup 

The setup message sent by the UE contains either a multimedia BC-IE indicating a multimedia only call request 

(i.e. no fallback to speech allowed) or both a speech BC-IE and a 3.1kHz multimedia BC-IE to indicate the support of a 

fallback to speech (see 3GPP TS 27.001 and 3GPP TS 24.008). 

The MSC shall not accept a requested service to which the user has no subscription. On the condition the user has the 
required subscriptions (i.e. to multimedia and/or speech) the following applies: 

in case of a multimedia only BC-IE the MSC may accept the setup as such or with modifications sent to the UE 
in the call proceeding message (see 3GPP TS 27.001); 

in case of both a speech BC-IE and a 3.1kHz multimedia BC-IE the MSC may either accept the possibility of a 
fallback to speech by responding with two BC-IEs or turn the call to a speech call by sending only a speech BC- 
IE in the call proceeding message or turn the call to a multimedia only call by sending only a multimedia BC-IE 
in the call proceeding message (See 3GPP TS 27.001). 

The IWF V.34 modem shall initiate the ITU-T Recommendation V.8 handshaking and indicate the support of H.324/M 
in the call function category of the V.8 handshaking. If the called party's modem does not indicate a H.324 support in its 
V.8 inband signalling response, the IWF may clear the call. If the called party responds with a modem answering tone 
but there is no V.8 response at all, the IWF shall clear the call. 

If FNUR = 33.6 kbit/s is agreed on in the setup, the IWF shall configure its V.34 modem to operate in automode with an 
upper data rate limit of 33.6 kbit/s and a lower data rate limit of 28.8 kbit/s. If the modems handshake to 3 1 .2 kbit/s or 
28.8 kbit/s, the MSC shall initiate a MODIFY message (see 3GPP TS 24.008) to indicate the new data rate to the UE. 
HDLC flag stuffing or the stuffing mode defined in ITU-T Recommendation H.223 (Annexes A, B and C) shall be used 
to adapt the 31.2 kbit/s or 28.8 kbit/s data rate to the 33.6 kbit/s traffic channel between the UE and the IWF. In order to 
be able to use the correct stuffing pattern, the IWF shall detect the stuffing mode patterns exchanged between the 
multimedia terminals after the traffic channel setup (see ITU-T Recommendation H.324). The IWF may start the 
stuffing immediately after the detection of the used method. In downlink stuffing the IWF inserts stuffing patterns 
between the H.223 frames. In uplink stuffing the IWF removes stuffing patterns from between the H.223 frames 
received from the UE. If the UE responds with a MODIFY REJECT message, the MSC shall clear the call. 

9.4.1 .2 Fallback to speech after setup 

If the MSC has accepted the possibility of a fallback to speech and the IWF modem does not recognize the answering 
tone of the called modem within the expiration of a timer started at the reception of the answer message, the MSC IWF 
shall initiate an In Call Modification procedure (see 3GPP TS 24.008) in order to fall back to a speech mode. As a result 
of the procedure the IWF resource shall be released and a speech channel shall be set up between the calling UE and the 
fixed network. If the fallback fails e.g. due to a failing In Call Modification procedure, the IWF shall clear the call. 

A recommended minimum value for the timer is 3 seconds (see ITU-T Recommendation V.25). 

9.4.2 Mobile terminated multimedia call 
9.4.2.1 Call setup 

If the user has a subscription to both the multimedia bearer service and the speech teleservice and if the network 
supports both services and the fallback functionality, the MSC shall send both a multimedia BC-IE and a speech BC-IE 
in the setup message to the user equipment. If the user has a subscription only to the multimedia bearer service the MSC 
shall send only a multimedia BC-IE. 

In case of both a speech BC-IE and a 3, 1 kHz multimedia BC-IE in the setup the user equipment may either accept the 
possibility of a fallback to speech by responding with two BC-IEs or turn the call to a speech call by sending only a 
speech BC-IE in the call confirmed message or to a multimedia only call (i.e. no fallback to speech allowed) by sending 
only a multimedia BC-IE in the call confirmed message. In case of a multimedia only BC-IE in the setup the UE may 
accept the setup as such or with modifications sent to the MSC in the call confirmed message. 
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If no service definition is available in the network, the MSC shall send no BC-IE(s) to the user equipment in the call 
setup. The MSC shall analyse the received BC-IE(s) and optionally perform a subscription check to the multimedia 
and/or speech service(s) requested by the user equipment in the call confirmed message and shall not accept a requested 
service rejected by the subscription check. 

The IWF V.34 modem shall await the ITU-T Recommendation V.8 handshaking to be initiated by the calling party's 
modem and shall recognize the support of H. 324 in the call function category of the incoming V.8 handshaking. If the 
calling party's modem does not indicate a H.324 support in its V.8 inband signalling, the IWF may clear the call. If the 
calling modem tries to handshake another than V.34 modem scheme, the IWF shall clear the call. 

If FNUR = 33.6 kbit/s is agreed on in the setup, the IWF shall configure its V.34 modem to operate in automode with an 
upper data rate limit of 33.6 kbit/s and a lower data rate limit of 28.8 kbit/s. If the modems handshake to 3 1 .2 or 28.8 
kbit/s, the MSC shall initiate a MODIFY message (see 3GPP TS 24.008) to indicate the new data rate to the UE. HDLC 
flag stuffing or the stuffing mode defined in ITU-T Recommendation H.223 (Annexes A, B and C) shall be used to 
adapt the 31.2 or 28.8 kbit/s data rate to the 33.6 kbit/s traffic channel between the UE and the IWF. In order to be able 
to use the correct stuffing pattern, the IWF shall detect the stuffing mode patterns exchanged between the multimedia 
terminals after the traffic channel setup (see ITU-T Recommendation H.324). The IWF may start the stuffing 
immediately after the detection of the used method. In downlink stuffing the IWF inserts stuffing patterns between the 
H.223 frames. In uplink stuffing the IWF removes stuffing patterns from between the H.223 frames received from the 
UE. If the UE responds with a MODIFY REJECT message, the MSC shall clear the call. 

9.4.2.2 Fallback to speech after setup 

If the MSC supports a fallback to speech and the user has a subscription to the speech service and the user equipment 
accepts the possibility of a fallback to speech in the call confirmed message and the IWF modem does not recognize a 
call tone nor a V.8 Call Indication nor a V.8 Call Menu within the expiration of a timer started at the sending of the 
ANSam answer tone (i.e. the calling party is not a V.34 modem), the IWF shall initiate an In Call Modification 
procedure (see 3GPP TS 24.008) in order to fall back to a speech mode. As a result of the procedure the IWF resource 
shall be released and a speech channel shall be set up between the called UE and the fixed network. If the fallback fails 
e.g. due to a missing subscription to speech or a failing In Call Modification procedure, the IWF shall clear the call. 

A recommended minimum timer value is 3 seconds (see ITU-T Recommendation V.8). 



9.4.3 Seamless data rate change 



If the modems change the data rate during an ongoing multimedia call (using the ITU-T Recommendation V.34 
seamless data rate change mechanism), the MSC shall initiate a MODIFY message (see 3GPP TS 24.008) to indicate 
the new data rate to the UE. HDLC flag stuffing or the stuffing mode defined in ITU-T Recommendation H.223 
(Annexes A, B and C) shall be used to adapt the 31.2 or 28.8 kbit/s data rate to the 33.6 kbit/s traffic channel between 
the UE and the IWF. The stuffing pattern found out during the traffic channel setup (see subclauses Call setup) is used. 
The IWF may start the stuffing immediately after the detection of the data rate change by the modems. 



1 Interworking to the ISDN 



The interworking to the ISDN is specified on the principle of the network supporting standardized associated signalling 
protocol as outlined in clause 6, i.e. DSSl and ISUP. An ISDN not complying with this definition differs - for the 
purpose of the present document - in that it does not support the compatibility information to that degree necessary for 
deducing a PLMN Basic Service. These networks will find their reflection in the following where those implications are 
to be set out. 

The calling address sent in a mobile originated call to the ISDN is always the basic MSISDN even if the ISDN user 
shall use a different MSISDN (multi numbering scheme, see 9.2.2 case a) for a mobile terminated call (call back) as 
only the basic MSISDN is available at the VLR (see 3GPP TS 29.002). 

The scope of this clause is to describe the handling of the content of the Information Elements where "content" is 
understood to be the value of the parameter fields of the Information Elements, namely BC-IE, HLC and LLC, after the 
length indicator. For the transport of these Information Elements within the PLMN refer to 3GPP TS 29.002. 
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The handling of muhislot, 14.4kbit/s, EDGE and lu Mode related parameters of the call control signalling and the 
applicability of single- or multislot configurations (refer to 3GPP TS 48.020 and 3GPP TS 44.021) is the same as for the 
PSTN interworking cases. 



10.1 Speech Calls 



Since at the interworking point the transcoder provides for A-law or |i-law (PCS-1900) PCM at 64 kbit/s, no particular 
interworking is required. It is anticipated that the ISDN Teleservice Telephony and ISDN Bearer Service speech, 
respectively would be used. Transmission aspects are covered in 3GPP TS 43.050. Any further requirements are a 
national matter. 

10.2 Data Calls 

In this case it is assumed that the ISDN bearer service 3,1 kHz audio shall only be interworked by means of a modem 
pool in the PLMN. If a network operator provides this facility, then the MSC/IWF operation will be similar to that 
described for interworking to the PSTN. 

Where the bearer capability information indicates that the call is a circuit switched unrestricted digital call, then the 
MSC/IWF shall select the appropriate rate adapted ISDN and PLMN bearer services. 

1 0.2.1 Network interworking mobile originated 

Low layer compatibility checking of the mobile originated call is carried out by the MSC/IWF to determine the 
appropriate bearer service selection in the ISDN. This will entail the MSC/IWF in mapping appropriately the PLMN 
BC-IE to the ISDN BC-IE (bearer capability information element). If it is not possible for the MSC/IWF to provide a 
bearer service match, then the MSC/IWF shall fail the call and indicate the reason to the user. 

The UE shall provide further compatibility information (LLC/HLC-IEs) if required for defining end-to-end 
compatibility. 

As well as compatibility checking, subscription checking should be performed. 

The selection of the MSC/IWF will be by means of the bearer capability information within the call set up message. The 
mobile subscriber shall be able to select the unrestricted digital capability, which the MSC/IWF will map to the same 
capability in the ISDN call set up message. If an interworking point is encountered within the ISDN which does not 
support this service request, then either a call release message including an appropriate error cause or progress message 
is returned to the PLMN, indicating that the ISDN network is unable to support the service requested. In the case of a 
call release message the network shall release the call. In the case of progress message the network releases the call or 
forwards it (see 3GPP TS 24.008) to the mobile which will release the call. 

1 0.2.2 Network interworking mobile terminated 
10.2.2.1 General 

This subclause describes the interworking of calls where the calling subscriber can communicate ISDN compatibility 
information with exhaustive contents for deducing a PLMN Basic Service to a PLMN (gateway MSC/interrogating 
node) i.e. by means of ISDN signalling. 

The GMSC shall perform a mapping of the received Basic Service Information for the transport to the HLR, for details 
of this transport refer to 3GPP TS 29.002. 

Compatibility checking of the low layers of the ISDN originated call is carried out by the MSC/IWF to determine the 
appropriate bearer service selection in the PLMN. This will entail the MSC/IWF in mapping appropriately the ISDN 
BC/LLC-IE to the PLMN BC-IE. 

As well as compatibility checking, subscription checking should be performed. If either the subscription check or the 
compatibility check fails then the call will be rejected. 

For ISDN originated calls it will not be possible to signal mobile specific requirements e.g. transparent/non transparent, 
full/half rate channel. Therefore the MSC/IWF shall select a default setting appropriate to the visited PLMN's network 
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capabilities. In general it will be beneficial, where a network supports both full and half rate channels and 
transparent/non transparent capabilities, to indicate so in the appropriate PLMN BC field of 3GPP TS 24.008. The 
mobile subscriber has the option to indicate in the call confirmation message a change to this default setting according 
to the rules specified in 3GPP TS 27.001. The appropriate MSC/IWF shall be selected on the basis of this requirement. 

1 0.2.2.2 Functions in GIVISC 

At call Set-up, the interrogating node passes in the "send routing information" to the HLR, the ISDN BC, LLC and HLC 
received in the initial address message. The coding of these parameters shall comply with Q.931 (05/98). For MT calls, 
and for backward compatibility purposes only, the mapping of the modem type according to ETS 300-102-1 (12/90) 
shall also be accepted, see note 12 of table 7B. 

The information possibly signaled backwards from the VMSC to the GMSC contained in the access transport parameter 
of the Answer message (ANM) can be used to perform service related functions (e.g. accounting) at the GMSC. 

10.2.2.3 Functions in HLR 

According to the contents of the Compatibility Information, i.e. the ISDN BC, LLC and HLC received, the HLR applies 
one of the following: 

1) No ISDN BC is received, or one from which a PLMN Basic Service cannot be deduced (i.e. with the information 
Transfer Capability field set to "3,1 kHz audio" but without any associated modem type^ in the ISDN BC and 
LLC, or without HLC indication of group 3 facsimile). Two cases shall be considered: 

a) The called MSISDN has a corresponding PLMN BC stored in the HLR (see 9.2.2.1); then the service 
attached to this number in the HLR tables is applicable and the corresponding PLMN BC is passed to the 
VLR in the "Provide Roaming Number" request. See figure 8; 

b) The called MSISDN has no corresponding PLMN BC stored in the HLR (see 9.2.2.2). In this case no PLMN 
BC is passed to the VLR in the "Provide Roaming Number" request. 

2) Compatibility Information is received from which a PLMN Basic Service can be deduced, i.e. the ITC field in 
the ISDN BC is "unrestricted digital" and the fields for the applicable user layer 1 protocol and user rate (except 
for the 64kbit/s case, see Note 22 Table 7B) are available (in either the ISDN BC or the LLC), or the ITC field is 
"3,1 kHz audio", and a modem type, user rate, etc. is indicated but the HLC does not indicate "facsimile group 
3". The received ISDN BC (and possibly LLC plus HLC) is then considered applicable regardless of the kind of 
MSISDN received (PLMN BC associated or not) and either the equivalent PLMN BC or the original ISDN 
BC/LLC is sent to the VLR. In both cases the originally received HLC may also be sent to the VLR; see figure 9. 

As an exception to this the BC stored in the HLR is regarded as valid if one of the following cases applies: 

- If ITC = UDI/RDI and User Rate = 32 kbit/s /56 kbit/s and User information layer 1 protocol = V. 1 10, 
I.460/X.30 and the stored BC indicates FTM, PIAFS or Multimedia. 

- If ITC = 3,1 kHz audio and User Rate = 28.8 kbit/s and Modem Type = V.34 and the stored BC indicates 
Multimedia. 

When the HLR interworks with a GSM phase 1 VPLMN (VLR/VMSC), then the HLR shall convert the ISDN 
BC to the equivalent PLMN BC, and forward it to the VLR. In this case the LLC cannot be forwarded. 

3) Compatibility Information is received from which the PLMN Teleservice category Facsimile transmission can be 
deduced, i.e. the ITC field in the ISDN BC is "3,1kHz audio" and the HLC indicates "facsimile group 3" (see 
figure 9). The following two cases shall be considered: 

a) The called MSISDN has a corresponding PLMN BC stored in the HLR (indicating either TS 61 or TS 62). In 
this case the service attached to the MSISDN in the HLR tables is applicable and the corresponding PLMN 
BC is passed to the VLR in the "Provide Roaming Number" request; see also subclause 10.3.1.3; 



"Modem type" in connection witli the ITC value "3,1 kHz audio" means hereafter that either an ISDN BC modem type value is present or the 
autobauding modem function is indicated (see note 16 of table 7B) 
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b) The called MSISDN has no corresponding PLMN BC stored in the HLR. In this case the HLR shall forward 
the appropriate PLMN BC to the VLR in line with the subscriber's subscription to Teleservice TS 61 or 
TS62. 

For TS 61 the value of the PLMN BC parameter "Information Transfer Capability" shall be set to "alternate 
speech/facsimile group 3, starting with speech". 

In both cases the HLC should be passed to the VLR in the "Provide Roaming Number" request. 

Alternatively the HLR may forward the originally received ISDN/LLC/HLC, when interworking with a GSM 
or later phase 2 VLR 

4) If the Compatibility Information received does not allow the HLR to deduce a PLMN Bearer Service, i.e. the 
ITC field in the ISDN BC is "unrestricted digital", but without the fields indicating the applicable user layer 1 
protocol, user rate, etc. (in either the ISDN BC or the ISDN LLC), then the call is managed as for a UDI call 
according to subclause 9.2.2, i.e. either the "multi numbering" or "single numbering" scenario is applied 
depending on which capability is provided by the home PLMN/HLR. 

5) Compatibility information is received, the ITC field in the ISDN BC is "speech" and this value differs from the 
ITC field in the PLMN BC stored in the HLR. Then the PLMN BC stored in the HLR is considered applicable 
and shall be sent to the VLR. 

If the HLR supports the option to return the MAP "GSM Bearer Capability" to the GMSC in the MAP "Send Routing 
Information" response, it shall pass the PLMN-BC stored in the HLR if the latter is considered applicable as per the 
preceding rules. Otherwise no MAP "GSM Bearer Capability" shall be returned. This requirement shall apply 
irrespectively of whether the MAP "Send Routing Information" response contains a MAP "MSRN", "GMSC Camel 
Subscription Info", "Forwarding Data" or not. As an exception, to avoid transferring twice the MAP "GSM Bearer 
Capability" for a call involving two MAP "Send Routing Information" procedures to the HLR, the HLR should not 
include the MAP "GSM Bearer Capability" in the MAP "Send Routing Information" response if the MAP "Send 
Routing Information" request contains the MAP "Suppress T-CSI" IE. 

10.2.2.4 Functions in VMSC 

When the incoming call arrives, the VMSC attempts to derive a PLMN basic service from the information received in 
the lAM, and requests information from the VLR to handle the call. In general, the LLC and HLC are sent with the 
PLMN BC to the UE at call set-up. In particular, however the following rules apply: 

1) If the Initial Address Message (lAM) contains no ISDN BC and no PLMN or ISDN BC/LLC/HLC was retrieved 
from the VLR, the call is handled as in subclause 9.2.2.2. 

2) If there is no ISDN BC in the lAM but a PLMN or ISDN BC/LLC/HLC was retrieved from the VLR, the PLMN 
or ISDN BC/LLC/HLC retrieved from the VLR applies. 

3) If there is an ISDN BC in the lAM with the ITC field set to "3,1 kHz audio" but without any associated modem 
type or indication of facsimile group 3 in the HLC, the PLMN or ISDN BC/LLC/HLC retrieved from the VLR is 
considered as applicable when it exists. If no PLMN or ISDN BC is retrieved from the VLR, the call is handled 
as in subclause 9.2.2.2. 

4) If there is an ISDN BC in the lAM with the ITC field set to "unrestricted digital information" and the fields for 
the applicable user layer 1 protocol and user rate (except for the 64kbit/s case; see note 22 to table 7B) are 
available (either in the ISDN BC or ISDN LLC), or if 3,1 kHz audio and a modem type is indicated, this ISDN 
BC is applicable regardless of what has been retrieved from the VLR. In this case the ISDN BC shall be mapped 
to an appropriate PLMN BC (refer to table 7B). 

As an exception to this the BC retrieved from the VLR is sent to the UE if one of the following applies: 

If ITC = UDI/RDI and User Rate = 32 kbit/s /56 kbit/s and User information layer 1 protocol = V. 110, 
I.460/X.30 and the BC retrieved from the VLR indicates FTM, PIAFS or Multimedia. 

If ITC = 3,1 kHz audio and User Rate = 28,8 kbit/s and Modem Type = V.34 and the BC retrieved from the 
VLR indicates Multimedia. 

5) If there is an ISDN BC in the lAM with the ITC field set to "3,1kHz audio" and there is an HLC indicating 
"facsimile group 3", the PLMN BC retrieved from the VLR is applicable when it exists. If a PLMN BC with the 
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parameter "information transfer capability" set to "alternate speech/facsimile group 3, starting with speech" (i.e. 
TS 61) is retrieved from the VLR, this shall be mapped to two PLMN BC-IEs preceded by a repeat indicator, 
one representing speech, the other representing facsimile group 3. 

For TS 61, the order in which the two PLMN BC-IEs are sent towards the UE in the setup message is a network 
option. 

6) If there is an ISDN EC in the lAM with the ITC field set to "unrestricted digital information" but without 

applicable "user layer 1 protocol" and "user rate", etc. fields, in either the ISDN BC no the ISDN LLC, then the 
PLMN or ISDN BC/LLC retrieved from the VLR is applicable, if available, otherwise subclause 9.2.2.2 applies. 

7) If there is an ISDN BC in the lAM with the ITC field set to "Speech" and this value differs from the ITC 
field of the BC retrieved from the VLR for this call, then the BC/LLC/HLC retrieved from the VLR is 
considered applicable. If no PLMN or ISDN BC is retrieved from the VLR, the call is handled as in subclause 
9.2.2.2. 

In all cases where the VMSC retrieves a PLMN BC from the VLR, the VMSC may add or modify PLMN-specific 
parameters in the PLMN BC, as described in subclause 9.2.2, before sending the PLMN BCD IE towards the UE. 

In all cases when no PLMN or ISDN BC is retrieved from the VLR and no ISDN Compatibility information allowing 
deduction of a PLMN Bearer Service is available, then no PLMN BC is inserted by the VMSC and subclause 9.2.2.2 
applies. 

The mapping between PLMN and ISDN BCs is shown in table 7. 

The UE may negotiate parameters with the MSC according to the rules defined in 3GPP TS 27.001. If the UE proposes 
to the network to modify the User Rate as well as the correlated parameters Modem Type and Intermediate Rate in the 
call confirmed message, the network may accept or release the call (see 3GPP TS 27.001). For multislot, 14.4kbit/s, 
EDGE and lu Mode operations, the UE may also propose to the network to modify the Fixed Network User Rate and 
Other Modem Type parameters (see 3GPP TS 27.001). In case a transparent service is used, the call shall be released. 
For a non-transparent service with flow control, the MSC/IWF shall use towards the fixed network the unmodified 
"fixed network user rate" and shall use the "wanted air interface user rate" or the modified "fixed network user rate" 
towards the user equipment. 

The VMSC may map the received PLMN BC into an ISDN BC according to the rules defined in table 7A. This ISDN 
BC can be transported together with possibly available LLC and HLC in the access transport parameter of the Answer 
message (ANM) according to ITU-T Q.763. 

10.2.2.4A Functions in VLR 

When the VLR receives from the VMSC a request for information to handle an incoming call, it performs two 
functions: 

1) It determines the basic service which applies for the call, according to the following principles: 

a) If the basic service received in the request from the VMSC was the same as the basic service indicated by the 
compatibility information received in the "Provide Roaming Number" request, the VLR applies that basic 

service. 

b) If the basic service received in the request from the VMSC was Telephony but the compatibility information 
received in the "Provide Roaming Number" request indicated a basic service different from Telephony, the 
VLR applies the basic service derived from the compatibility information received in the "Provide Roaming 
Number" request. 

c) If the basic service received in the request from the VMSC was Facsimile Group 3 and the compatibility 
information received in the "Provide Roaming Number" request indicated Alternate Speech and Facsimile 
Group 3, the VLR applies the basic service Alternate Speech and Facsimile Group 3. 

d) If the basic service received in the request from the VMSC was Telephony and no compatibility information 
was received in the "Provide Roaming Number" request, the VLR applies the basic service Telephony. 

e) If the basic service received in the request from the VMSC was Facsimile Group 3 but no compatibility 
information was received in the "Provide Roaming Number" request, the VLR checks the subscription 
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information stored in its database, and applies the appropriate subscribed basic service (Facsimile Group 3 or 
Alternate Speech and Facsimile Group 3). 

f) If the basic service received in the request from the VMSC was anything except Telephony or Facsimile 
Group 3, the VLR applies the basic service received in the request from the VMSC, regardless of any 
information received in the "Provide Roaming Number" request or stored subscription information. 

g) If no basic service was received in the request from the VMSC but compatibility information was received in 
the "Provide Roaming Number" request, the VLR applies the basic service derived from the compatibility 
information received in the "Provide Roaming Number" request. 

h) If no basic service was received in the request from the VMSC and no compatibility information was 
received in the "Provide Roaming Number" request, the VLR applies the basic service determined by the 
network operator, taking account of the subscribed basic services. 

2) It returns compatibility information (PLMN BC or ISDN BC, and possibly ISDN HLC and ISDN LLC, 
according to the following principles: 

a) If the request from the VMSC included a basic service Facsimile Group 3, the VLR checks the subscription 
information stored in its database, and returns the appropriate compatibility information according to the 
subscribed basic service: 

i) A PLMN BC with the parameter "information transfer capability" set to "alternate speech/facsimile group 
3, starting with speech" (i.e. TS 61) if the subscribed basic service is Alternate Speech and Facsimile 
Group 3; 

ii) A PLMN BC with the parameter "information transfer capability" set to " facsimile group 3" (i.e. TS 62) 
if the subscribed basic service is Facsimile Group 3. 

b) If the request from the VMSC did not include a basic service Facsimile Group 3 and compatibility 
information was received in the "Provide Roaming Number" request, the VLR processes the compatibility 
information received in the "Provide Roaming Number" request: 

i) If the compatibility information received in the "Provide Roaming Number" request consisted of an ISDN 
BC/LLC/HLC the VLR maps this to an appropriate PLMN BC as shown in table 7B. 

ii) If the compatibility information received in the "Provide Roaming Number" request consisted of a PLMN 
BC, possibly with an ISDN LLC/HLC, the VLR retains the PLMN BC 

c) If the request from the VMSC did not include a basic service Facsimile Group 3 and no compatibility 
information was received in the "Provide Roaming Number" request, the VLR sends no compatibility 
information to the VMSC. 
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10.2.2.5 Call Flows 
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(BC'"gk) 




NOTE: (1) Some parameters of BCgk may be provided/modified according to the MSC's capabilities/preferences. 
See subclause 9.2.2. 

(2) In the "Call Confirm" message, the UE may modify some parameters of the PLIVIN BC. See 
subclause 9.2.2. 

(3) The VMSC may map the PLMN BC (BC""gk) Into an ISDN BC (BC gk) according to the rules defined 

in table 7A 

(4) Abbreviations: see figure 2. 

Figure 8: Call Flow for a mobile terminated, ISDN originated call 

where compatibility information provided are not exhaustive for deducing a PLMN Bearer Service, 

but Information Transfer Capability = 3,1 kHz audio, no modem type and no HLC IE indicating 

facsimile group 3 HLR stores PLMN BC against MSISDN number multi-numbering scheme 



£75/ 



3GPP TS 29.007 version 9.1.0 Release 9 



44 



ETSI TS 129 007 V9.1.0 (2010-10) 



UE 



VMSC 



VLR 



HLR 



(GSM 
IP 



^ Setui 

pC'gj, LLC. 

Call Conf. 



(BC'gj, LLC, HLC) 



Connect 



-> 



PRN 



SRI 



(LLCHLCBQj) 



(GSM BCgj/HLC or BCij/LLC/HLC) 
(MSRN) 



SIFICSU 



lAM 
(BCij, MSRN) 



^ 



(MSRN) 
Com p. Call 
Bbgj/HLC or Bdij/LLC/HLC) 



HLC) 



(MSRN) 



ANM 



(BC'gj, LLC, HLC) 



-> 



lAM 

(LLC HLC BCij) 
(6) 



(1) 
(6) 



(2) 
(3) 



(4) 
(5) 

(7) 



NOTES: (1) BCij denotes ISDN BC*; BCgj is tlie corresponding PLIVIN BC. 

(2) Assumes signalling capabilities permit the transfer of BC between IN and VMSC. If this is not the case, 
the VLR uses the stored BC/LLC/HLC. 

(3) BCij denotes BCij as maybe modified by intervening networks. 

(4) Some parameters of BCgk may be provided/modified according to the IVISC's capabilities/preferences. 
See subclause 9.2.2. 

(5) In the "Call Confirm" message, the UE may modify some parameters of the BC. See subclause 9.2.2. 

(6) For details on how the BC, HLC, and LLC are transported, refer to 3GPP TS 29.002. 

HLC and LLC refers to ISDN values. 

(7) The VMSC may map the PLMN BC (BC""gj,LLC,HLC) into an ISDN BC (BC gj,LLC,HLC) according 

to the rules defined in table 7A 

(8) Abbreviations: see figure 2. 

Figure 9: Call Flow for a mobile terminated, ISDN originated call 

where compatibility information provided are sufficient information to deduce a PLMN Bearer Service 

or Information Transfer Capability = 3,1 kHz audio with HLC IE indicating facsimile group 3 

10.2.2.6 Mapping Functions 

The following tables (7A + 7B) show that only the ISDN BC is used for mapping (exceptions are indicated). 

NOTE: The ISDN/PLMN BC-IE mapping shall be performed as specified in tables 7 A and 7B. This shall be done 
to allow setup of a compatible end-to-end connection between two UEs or one UE and an ISDN terminal. 

In the following tables 7A and 7B the comparison is drawn between parameters in the PLMN call set up request 
message and that of the ISDN call set up request message. In some cases no comparable values are available and these 
will be marked as such. In these cases reference will need to be made to the table of network interworking in 3GPP 
TS 29.007 to identify the appropriate choice. In some cases it is not necessary to support a particular option, and in this 
case those parameters will be annotated appropriately. 
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The PLMN parameters and values are as in 3GPP TS 24.008 in combination as in 3GPP TS 27.001. The ISDN 
parameters and values are as in Q.931 (05/98). 
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Table 7A: Comparable setting of parameters in PLIUIN and ISDN: Mobile Originated 



Octet 


PLMN BC parameter value 


Octet 


ISDN BC parameter value 


1 


Bearer Capability lEI 


1 


Bearer Capability lEI 


2 


Length of BC contents 


2 


Length of BC contents 


3 
#7..6 


Radio channel requirement 

half rate channel 
full rate channel 
dual, full, rate preferred 
dual, half rate preferred 




No comparable field 


3 
#5 


Coding Standard 

GSM standard coding 


3 
#7..6 


Coding Standard 

CCITT standardized coding 


3 

#4 


Transfer mode 

circuit mode 
packet mode (note7) 


4 
#7..6 


Transfer mode 
circuit mode 
packet mode 


3 
#3..1 


Information transfer capability 

speech 

unrestricted digital 

3,1 kHz audio ex PLMN 

facsimile group 3 (note 1)_ 

other lie (see octet 5a) 


3 
#5..1 


Information transfer capability 

speech 

unrestricted digital 
3,1 kHz audio 
3,1 kHz audio 
no comparable value 

(note 18) 


5a 
#7..6 


Other ITC 

restricted digital 


4 
#7 


Compression (note 14) 
data compression allowed 
data compression not allowed 




No comparable field 


4 

#6..5 


Structure 

SDU integrity 
unstructured 


4a 

#7..5 


Structure (note 4) 


4 
#4 


Duplex mode 

half duplex 
full duplex 


5d 

#7 


Duplex mode 

half duplex 
full duplex 


4 
#3 


Configuration 

point to point 


4a 
#4.. 3 


Configuration (note 4) 


4 
#1 


Establishment 

demand 


4a 
#2..1 


Establishment (note 4) 


4 


NIRR(note12) 

no meaning 

Data < 4.8kbit/s, FR nt, 

6kbit/s radio interface is requested 




No comparable field 


5 

#5..4 


Rate adaptation 

no rate adaptation (note 2) 
V.110, I.460/X.30 rate adaptation 

CCITT X.31 flag stuffing (note 25) 

No comparable value(note 1 1 )_ 
No comparable value(note 11) 

No comparable value(note 1 1 ) 

other rate adaptation (see octet 5a) 


5 
#5..1 


User information layer 1 protocol 

no comparable value 
CCITT standardized rate adaption 
V.110, I.460/X.30 
(note 25) 

Recommendation G.71 1 |j-law 
Recommendation G.71 1 A-law (note 

3) 

Recommendation G.721 32 kbit/s 

ADPGM and 1.460 

No comparable value 

No comparable value 
H.223 & H.245 (note 26) 


5a 

#5..4 


Other rate adaptation 

V.120(note17) 
PIAFS (note 27) 
H.223 & H.245 


5 
#3..1 


Signalling access protocol 

1.440/1.450 

X.21 (note 24) 

X.28, ded.PAD, indiv.NUI (note 24) 

X.28, ded PAD, univ.NUI (note 24) 

X.28, non-ded PAD (note 24) 

X.32 (note 24) 




No comparable field 


6 

#1 


Synchronous/asynchronous 

synchronous 
asynchronous 


5a 
#7 


Synchronous/asynchronous 

synchronous 
asynchronous 


6 


User info, layer 1 protocol 


5 


User info, layer 1 protocol 
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Octet 


PLMN BC parameter value 


Octet 


ISDN BC parameter value 


#5..2 


default layer 1 protocol 


#5..1 


see section under rate adaptation for 
3GPP TS 24.008 above 


6a 


Number of stop bits 


5c 


Number of stop bits 


#7 


1 bit 


#7..6 


1 bit 




2 bits 




2 bits 


6a 


Negotiation 


5a 


Negotiation 


#6 


In band neg. not possible 


#6 


In band neg. not possible 




no comparable value 




In band neg. possible (note 10) 


6a 


Number of data bits 


5c 


Number of data bits excluding 


#5 




#5.. 4 


parity if present 




7 bits 




7 bits 




8 bits 




8 bits 


6a 


User rate 


5a 


User rate 


#4..1 


0.3 kbit/s 


#5..1 


0.3 kbit/s 




1 .2 kbit/s 




1 .2 kbit/s 




2.4 kbit/s 




2.4 kbit/s 




4.8 kbit/s 




4.8 kbit/s 




9.6 kbit/s 




9.6 kbit/s 




12 kbit/s (note 7) 




1 2 kbit/s 




1 .2 kbit/s / 75 bit/s (note 24) 




75 bit/s / 1 .2 kbit/s 




any value 




19.2 kbit/s (note 14) 




no comparable value 




Ebits or inband negotiation 
(note 10) 


6b 


Intermediate rate 


5b 


Intermediate rate (note 1 3) 


#7..6 


8 kbit/s 


#7..6 


8 kbit/s or not used 




16 kbit/s 




1 6 kbit/s or not used 




any value 




32 kbit/s or not used (note 14) 


6b 


NIC on Tx 


5b 


NIC on Tx 


#5 


does not require 


#5b 


does not require 




requires (note7) 




requires (note 8) 


6b 


NIC on Rx 


5b 


NIC on Rx 


#4 


cannot accept 


#4 


cannot accept 




can accept (note 7) 




can accept (note 8) 


6b 


Parity information 


5c 


Parity information 


#3.-1 


odd 


#3..1 


odd 




even 




even 




none 




none 




forced to 




forced to 




forced to 1 




forced to 1 


6c 


Connection element 




No comparable field 


#7..6 


transparent 
non-transparent (RLP) 
both, transp. preferred 
both, non-transp. preferred 






6c 


Modem type 


5d 


Modem type 


#5..1 


none 


#6..1 


no comparable value (note 5) 




V.21 




V.21 




V.22 




V.22 




V.22bis 




V.PPhis 




V.23 (note 24) 




V.23 




V.26ter 




V.26ter 




V.32 




V.32 




modem for undef. interface 




No comparable value (note 5) 




autobauding type 1 




No comparable value (note 5, 
note 1 0) 


7 


User info, layer 2 protocol 


6 


User info.layer 2 prot. (note 6) 


#5..1 


X.25 link level (note 24) 




X.25 link level 




ISO 6429, codeset 




no comparable value 




COPnoFICt 




no comparable value 




videotex profile 1 (note 7) 




no comparable value 




X.75 layer 2 modified (CAPI) (note 24) 




X.25 link level 


6cl 


Fixed network user rate (note 1 5) 


5a 


User rate 


#5..1 


FNUR not applicable (note 7) 


#5..1 


no comparable value 




9,6 kbit/s 




9,6 kbit/s 




12 kbit/s (note 7) 




1 2 kbit/s 




14,4 kbit/s 




14,4 kbit/s 
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Octet 


PLMN BC parameter value 


Octet 


ISDN BC parameter value 




19,2kbit/s 
28,8 kbit/s 
32.0 kbit/s 
33.6 kbit/s 
38,4 kbit/s 
48,0 kbit/s 
56,0 kbit/s 
64,0 kbit/s 




19,2 kbit/s 

28,8 kbit/s 

32.0 kbit/s 

no comparable value 

38,4 kbit/s 

48,0 kbit/s 

56,0 kbit/s 

no comparable value (note 16) 


6e 
#3..1 


Maximum number of traffic channels 

1 TCH 
2TCH 

3 TCH 

4 TCH 

5 TCH 

6 TCH 

7 TCH (note 7) 

8 TCH (note 7) 




No comparable field 


6f 

#4..1 


Wanted air interface user rate (note 23) 

air interface user rate not applicable (note 

7) 

9,6 kbit/s 

14,4 kbit/s 

19,2 kbit/s 

28,8 kbit/s 

38,4 kbit/s 

43,2 kbit/s 

57,6 kbit/s 

interpreted by the network as 38.4 kbit/s 

(note 7) 




No comparable field 


6d 
#7..6 


Other modem type (note 15) 
No other modem type 
V.34 


5d 
#6..1 


Modem type 

no comparable value 
V.34 


6e 

#7..4 


Acceptable channel coding(s) 

TCH/F4.8 acceptable (note 19) 
TCH/F9.6 acceptable 
TCH/F1 4.4 acceptable 




No comparable field 


6f 
#7..5 


User initiated modification indicator 
(note 23) 

User initiated modification not 

required 
User initiated modification upto 1 

TCH/F may be requested 
User initiated modification upto 2 

TCH/F may be requested 
User initiated modification upto 3 

TCH/F may be requested 
User initiated modification upto 4 

TCH/F may be requested 




No comparable field 


6g 

#7..5 


Acceptable channel coding(s) (note 20) 

TCH/F28.8 acceptable 
TCH/F32.0 acceptable 
TCH/F43.2 acceptable (note 22) 




No comparable field 


6g 

#4..3 


Asymmetry preference indication (Note 
23) 

no preference 

up link biased asymmetry preference 

down link biased asymmetry preference 




No comparable field 



General Notes 

The application rules for coding the information elements ISDN-BC/LLC/HLC as set out in ETR 018 and Q.931 
(05/98) shall apply. 

Other field values in the ISDN BC-IE not supported in 3GPP TS 24.008 are: 

Information transfer rate: In this case default 64 kbit/s is selected. 
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Flow control on transmission: 

Flow control on reception: This shall be selected if outband flow control applies. Outband flow control 

is indicated by the absence of the UIL2P parameter for non-transparent 
connections. 

User information layer 3 protocol: Octet 7 shall not be sent unless specific application rules are given for 

particular cases (to be defined by PLMN). End-to-end significant User 
Information layer 3 protocol shall be sent by LLC. 

Notes regarding particular entries in table 7A: 

NOTE 1: If the PLMN BC "Information Transfer Capability" indicates "Facsimile group 3" and only a single 
PLMN BC is contained in the call set-up request then this shall be mapped to an ISDN BC with: 

coding standard: CCITT; 

information transfer capability: 3,1 kHz audio; 

transfer mode: circuit; 

information transfer rate: 64 kbit/s; 

user layer 1 protocol: G711 A-law or |i-law (PCS-1900); and 

if an HLC is not present, the network will insert a "Facsimile group 2/3" HLC; 

if an HLC element is present, the network will pass it through unmodified. 

If the PLMN BC "Information Transfer Capability" indicates "Facsimile group 3" and two PLMN BCs 
are contained in the call set-up request, then the same ISDN BC as mentioned above is created. If the first 
PLMN BC indicates "facsimile group 3" an HLC "facsimile group 2/3" will be inserted by the network (if 
not received from the UE). However if the first PLMN BC indicates "speech", the network will not send a 
HLC, irrespective where a HLC was received from the UE or not. 

NOTE 2: This value is present in combination with information transfer capability parameter value "3,1 kHz audio 
Ex PLMN" or "facsimile group 3" and will therefore be mapped to the value "Recommendation G.71 1 
A-law" or Recommendation G.7 11 |i-law" (PCS-1900) of the Q.931 (05/98) parameter user layer 1 
protocol (see note 3). 

NOTE 3: The value "Recommendation G.711 A-law" or "Recommendation G.711 |i-law" (PCS-1900) appHes only 
when the Q.931 (05/98) parameter information transfer capability indicates "3,1 kHz audio" or "speech". 

NOTE 4: When interworking with an ISDN according to ETS 300 102-1 octets 4a and 4b shall not be included 
because default values apply. In an ISDN according to Q.931 (05/98) these octets no more exist. 

NOTE 5: In this case octet 5d shall not be included. 

NOTE 6: Octet 6 shall not be sent unless specific application rules are given for a particular case 

(PLMN specified). End-to-end significant user information layer 2 protocol shall be sent by LLC. 

NOTE 7: Not used for currently defined Bearer Services and Teleservices. 

NOTE 8: These values will only be set if the "Information Transfer Capability" indicates "3,1 kHz audio", 
synchronous data transmission is used and octet 5b of the ISDN BC is present. 

NOTE 9: (VOID). 

NOTE 10: The PLMN BC-IE parameter value "autobauding modem type 1" will be mapped to the ISDN BC-IE 
parameter values "inband negotiation possible" and "user rate indicated by E-bits specified in ITU-T 
Recommendation 1.460 or may be negotiated inband" (octet 5a of ISDN BC-IE). If data compression is 
used, high speed modems, like V.32bis, V.34 and/or V.90 may be used in the IWF. Autobauding may 
also be used to support user rates less than 9.6 kbit/s towards the PSTN. 

NOTE ll:The ITC value of the PLMN BC-IE "speech", "3,1 kHz audio Ex PLMN" will indicate these 
requirements. 
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NOTE 12:For the use of NIRR see 3GPP TS 27.001. 

NOTE 13: The value of the Intermediate Rate field of the ISDN Bearer Capability information element shall only 
depend on the values of the User Rate and the Information Transfer Capability in the same information 
element. The correspondence is: 

Intermediate Rate = not used if User Rate > than 19.2 kbit/s. 
Intermediate Rate = 32 kbit/s if User Rate = 19,2 kbit/s or 14.4 kbit/s. 
Intermediate Rate = 16 kbit/s if User Rate = 9,6 kbit/s. 
Intermediate Rate = 8 kbit/s otherwise. 

For Audio calls the value of the Intermediate Rate may be set to "not used". 

NOTE 14: If compression is supported by the MSC and "data compression allowed" is indicated, then the ISDN user 
rate for UDI calls shall be set as follows. If the parameter "FNUR" is present the ISDN user rate shall be 
set to this value. Otherwise the PLMN user rate shall be mapped to an equal or any higher ISDN user rate 
value (for V.l 10 the highest ISDN user rate shall be 19,2 kbit/s). The Intermediate Rate shall be set to an 
appropriate value. (see subclause 10.2.4.11). 

For "3,1 kHz audio" the modem shall try to negotiate data compression and flow control (see subclause 
9.2.4.1 1). For "autobauding type 1" high speed modems may be used (see note 10). 

NOTE 15:User rate of the PLMN -BC is overridden by the fixed network user rate of the PLMN BC-IE if available. 
When the MT indicates „autobauding", „modem for undefined interface" or „none", the other modem 
type shall be set to „no other modem type"; any other value of the modem type is overridden by the other 
modem type value (see 3GPP TS 27.001). In lu mode, if octet 6d is not present in the PLMN BC, the 
MSC shall reject the call. The support of user rates lower than 9.6 kbit/s in lu mode are only possible in 
the scope of autobauding (see note 10). 

NOTE 16:In the case Other rate adaptation = H.223 & H.245 the ISDN BC-IE shall be coded as follows: 

Coding standard: ITU-T 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

User information layer 1 protocol: H.223 & H.245 

In all the other cases the ISDN-BC will consist of the octets 1 to 4 only, coded: 

Coding standard: CCITT 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

NOTE 17: V. 120 interworking is selected. 

If an LLC element is not present, the network will insert an LLC. If an LLC is present it may be modified. 
The PLMN -BC parameters negotiated with the UE shall be mapped to the LLC parameters. The LLC 
parameter Rate Adaptation will be set to "V.120". 

When interworking with unrestricted 64 kbit/s networks the ISDN BC shall be coded according to 
note 16. 

NOTE 18: When the MSC is directly connected to a restricted 64 kbit/s network, the ISDN BC-IE is coded with an 
ITC = RDI. 

When indirectly interworking with a restricted 64 kbit/s network the ISDN BC-IE shall be coded 
according to ETR 018, as shown below: 

Coding standard: CCITT 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

User information layer 1 protocol: V.l 10/X.30 

Synchronous/Asynchronous: synchronous 
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Negotiation: In-band negotiation not possible 

User rate: 56 kbit/s 

If an LLC element is not present, the network will insert an LLC. If an LLC is present it may be modified. 
The PLMN -BC parameters negotiated with the UE shall be mapped to the LLC parameters according to 
the rules in this table. The LLC parameter Information Transfer Capability will be set to „restricted 
digital" 

NOTE 19:If the UE signals an ACC containing TCH/F4.8 only and the network does not support TCH/F4.8 channel 
coding, then the MSC may act as if TCH/F9.6 were included in the ACC. 

NOTE 20: Extension of the 'Acceptable channel codings' field in octet 6e if EDGE channel codings are supported. 

NOTE 21: Void 

NOTE 22: Only applicable for non-transparent services. 

NOTE 23:This parameter shall be included if EDGE channel codings are indicated in ACC. In cases where this 
parameter would not otherwise be included, the value is set to 'Air interface user rate not applicable' or 
'User initiated modification not requested' or 'No preference'. 

NOTE 24: This value was used by services defined for former PLMN releases and does not need to be supported. 

NOTE 25:The case of FTM is identified by Rate adaptation in the PLMN BC-IE set to "CCITT X.31 flag stuffing". 
Connection element set to "non-transparent", and Synchronous/asynchronous set to "asynchronous". The 
MSC applies one of the following alternatives: 

1) IF FNUR=64 kbit/s 

- the ISDN BC-IE shall be coded as follows: 

Coding standard: ITU-T 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

- the LLC-IE shall be coded according to ETR 018 as follows: 

Coding standard: ITU-T 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

User information layer 1 protocol: (CCITT standardized rate adaptation 

X.31 HDLC flag stuffing) (note: the 
absence of octet 5 indicates that HDLC flag 
stuffing applies) 

User information layer 2 protocol: Recommendation X.25, link layer 

User information layer 3 protocol: Recommendation X.25, packet layer 

If user information layer 1 protocol is indicated by absence of octet 5 user information layer 
2/3 protocol are also absent. 

2) If FNUR=56 kbit/s and the MSC is directly connected to a 
restricted 64 kbit/s network: 

- the ISDN BC-IE shall be coded as follows: 

Coding standard: ITU-T 

Information Transfer capability: RDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

- the LLC-IE shall be coded as follows: 
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Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 



User information layer 2 protocol: 
User information layer 3 protocol: 



ITU-T 
RDI 

circuit 
64 kbit/s 

(CCITT standardized rate adaptation 
X.31 HDLC flag stuffing) (note: the 
absence of octet 5 indicates that HDLC flag 
stuffing applies) 

Recommendation X.25, link layer 
Recommendation X.25, packet layer 



If user information layer 1 protocol is indicated by absence of octet 5 user information layer 
2/3 protocol are also absent. 

3) If FNUR=56 kbit/s and the MSC is indirectly interworking 

with a restricted 64 kbit/s network: 

- the ISDN BC-IE shall be coded according to ETR 018, as shown below: 



Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 

Synchronous/Asynchronous: 

Negotiation: 

User rate: 



ITU-T 
UDI 

circuit 

64 kbit/s 

V.110/X.30 

synchronous 

In-band negotiation not possible 

56 kbit/s 



If an LLC element is not present, the network will insert an LLC. If an LLC is present it may be modified. The 

PLMN -BC parameters negotiated with the MS shall be mapped to the LLC parameters according to the 
rules in this table. The LLC parameter Information Transfer Capability will be set to „restricted digital" 
and the LLC parameter User information layer 1 protocol will be set to 'X.31 flag stuffing'. 



NOTE 26:If FNUR=64 kbit/s the ISDN BC-IE shall be coded as follows: 



Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 



ITU-T 
UDI 

circuit 

64 kbit/s 

H.223 and H.245 



If FNUR=56 kbit/s the ISDN BC-IE shall be coded as in note 18. 
If FNUR=32 kbit/s the ISDN BC-IE shall be coded as follows: 



Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 

Synchronous/Asynchronous: 

Negotiation: 

User rate: 



ITU-T 
UDI 

circuit 

64 kbit/s 

V. 110, 1.460 &X.30 

synchronous 

In-band negotiation not possible 

32 kbit/s 



If FNUR=28.8 kbit/s the ISDN BC-IE shall be coded as follows: 
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Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 

Synchronous/Asynchronous: 

Negotiation: 

Modem type: 

User rate: 



ITU-T 

3,1 kHz Audio 

circuit 

64 kbit/s 

G.71 1 A-law or |i-law 

synchronous 

In-band negotiation not possible 

V.34 

28.8 kbit/s 



If FNUR=33.6 kbit/s the ISDN BC-IE shall be coded as follows: 



Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 



ITU-T 

3,1 kHz Audio 

circuit 

64 kbit/s 

G.711 A-law or |i-law 



NOTE 27:If FNUR=32 kbit/s the ISDN BC-IE shall be coded for PIAFS as follows: 



Coding standard: 

Information Transfer capability: 

Transfer mode: 

Information transfer rate: 

User information layer 1 protocol: 

Synchronous/Asynchronous: 

Negotiation: 

User rate: 



ITU-T 
UDI 

circuit 

64 kbit/s 

V.llO, 1.460 and X.30 

synchronous 

In-band negotiation not possible 

32 kbit/s 



If FNUR=64 kbit/s the ISDN BC-IE shall be coded for PIAFS as in note 16. 
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Table 7B: Comparable setting of parameters in PLIVIN and ISDN: Mobile Terminated 



Octet 


ISDN BC parameter value 


Octet 


PLMN BC parameter value 


1 


Bearer Capability lEI 


1 


Bearer Capability lEI 


2 


Length of BC contents 


2 


Length of BC contents 




no comparable field 


3 
#7..6 


Radio channel requirement 

full rate channel (these bits are spare in the 
network to UE direction) 


3 
#7..6 


Coding standard 

CCITT standardized coding 


3 

#5 


Coding standard 

GSM standardized coding 


3 

#5..1 


Information transfer capability 

speech 

unrestricted digital 
3,1 kHz audio 
no comparable value 
no comparable value 
7 kHz audio 
video 

(note 23) 


3 
#3..1 


Information transfer capability 

speech 

unrestricted digital 

3,1 kHz audio ex PLIVIN (note2) 

facsimile group 3 (note 3) 

other ITC (see octet 5a) 

not supported 

not supported 


5a 
#7..6 


Other ITC 

restricted digital 


4 

#7..6 


Transfer mode 

circuit mode 
packet mode 


3 

#4 


Transfer mode 

circuit mode 
not supported 


4 

#5..1 


Information transfer rate 

64 kbit/s 




no comparable field 




No comparable field 


4 

#7 


Compression (note 18) 
data compression possible 
data compression not possible 




No comparable field (note 4) 


(4)4 
#6..5 


Structure (note 9) 
SDU integrity 
unstructured 


4a 
#4.. 3 


No comparable field (note 4) 


4 

#3 


Configuration 

point-to-point (note 5) 




No comparable field 


4 

#2 


NIRR (note 17) 

No meaning 

Data < 4.8 kbit/s, FR nt, 

6 kbit/s radio interface requested 


4a 

#2..1 


No comparable field (note 4) 


4 

#1 


Establishment 

demand (note 5) 


4b 
#7..6 








4b 

#5..1 








5 
#5..1 


User information layer 1 protocol 

no comparable value 
CCITT V.1 10, 1.460 /X.30 
G.711 A-law 

CCITT X.31 flag stuffing, 
no comparable value 

No comparable value 

H.221 & H.242(note 28) 
H.223 & H.245 


5 
#5.. 4 


Rate adaption 

no rate adaption (note 1 1 ) 

V.1 10, I.460/X.30 rate adaption 

no comparable value 

not supported, 

other rate adaption (see octet 5a) 


5a 
#5.. 4 


Other rate adaptation 

V.120(note24) 
PIAFS 

H.223 & H.245 
H.223 & H.245 




no comparable field 


5 
#3..1 


Signalling access protocol 

1.440/1.450 

X.21 (note 26) 

X.28, ded.PAD, indiv.NUI (note 26) 

X.28, ded.PAD, univ.NUI (note 26) 

X.28, non-ded.PAD (note 26) 

X.32 (note 26) 




any of the above values 


6 

#5..2 


User information layer 1 protocol 

default layer 1 protocol 


5a 
#7 


Synchronous / asynchronous 

synchronous 
asynchronous 


6 

#1 


Synchronous/asynchronous 

synchronous 
asynchronous 


5a 


Negotiation 


6a 


Negotiation 
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Octet 


ISDN BC parameter value 


Octet 


PLMN BC parameter value 


#6 


not possible 

inband neg, possible (note 16) 


#6 


not possible 

no comparable value 




5a 


User rate 


6a 


User rate (note 18 and 29) 




#5..1 


0,3 kbit/s 

1 ,2 kbit/s 

2,4 kbit/s 

4,8 kbit/s 

9,6 kbit/s 

1 2 kbit/s 

rate is indicated by Ebit as specified in rec. 

1.460 

0,6 kbit/s 

3,6 kbit/s 

7,2 kbit/s 

8 kbit/s 

14,4 kbit/s 

1 6 kbit/s 

19.2 kbit/s 

28.8 kbit/s 

32 kbit/s 

38.4 kbit/s 

48 kbit/s 

56 kbit/s 

57.6 kbit/s 

0,1345 kbit/s 

0,1 kbit/s 

75 bit/s / 1 ,2 kbit/s 

1 ,2 kbit/s / 75 bit/s 

0,1 10 kbit/s 

0,2 kbit/s 


#4..1 


0,3 kbit/s 

1 ,2 kbit/s 

2,4 kbit/s 

4,8 kbit/s 

9,6 kbit/s 

12 kbit/s (note 13) 

(note 16) 

not supported 
not supported 
not supported 
not supported 
(note 20) 
not supported 
(note 20) 
(note 20) 
(note 20) 
(note 20) 
(note 20) 
(note 20) 
not supported 
not supported 
not supported 
not supported 
not supported 
not supported 
not supported 




5b 


Intermediate rate 


6b 


Intermediate rate (note 6) (note 1 


8) 


#7..6 


not used (note 19) 
8 kbit/s 
1 6 kbit/s 
32 kbit/s 


#7..6 


8 or 16 kbit/s 
8 kbit/s 
1 6 kbit/s 




5b 


NIC on Tx (note 14) 


6b 


NIC on Tx 




#5 


does not require 
requires 


#5 


does not require 
requires (note 13) 




5b 


NIC on Rx (note 14) 


6b 


NIC on Rx 




#4 


cannot accept 
can accept 


#4 


cannot accept 

can accept (note 13) 




5b 


Flow control on Tx (note 1 5) 




no comparable field 




#3 


Not Required 
Required 








5b 


Flow control on Rx (note 15) 




no comparable field 




#2 


Cannot Accept 
Accept 








5c 


Number of stop bits 


6a 


Number of stop bits 




#7..6 


1 bit 

2 bits 
not used 
1 .5 bits 


#7 


1 bit 

2 bits 

no comparable value 
not supported 




5c 


Number of data bits 


6a 


Number of data bits 




#5.. 4 


7 bits 

8 bits 
not used 
5 bits 


#5 


7 bits 

8 bits 

no comparable value 
not supported 




5c 


Parity information 


6b 


Parity information 




#3..1 


odd 
even 
none 

forced to 
forced to 1 


#3..1 


odd 
even 
none 

forced to 
forced to 1 








6c 


Connection element (note 1) 








#7..6 


transparent 






no comparable field 




non-transparent (RLP) 
both, transp. preferred 
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Octet 


ISDN BC parameter value 


Octet 


PLMN BC parameter value 








both, non-transp preferred 


5d 


Duplex mode 


4 


Duplex mode 


#7 


half duplex 


#4 


half duplex (note 13) 




full duplex 




full duplex (note 5) 


5d 


Modem type 


6c 


Modem type (note 12) 


#6..1 


reserved 


#5..1 


none (note 7) 




V.21 




V.21 




V.22 




V.22 




V.22bis 




V.22bis 




V.23 




not supported 




V.26ter 




V.26ter 




V.32 




V.32 




V.26 




not supported 




V.26bis 




not supported 




V.27 




not supported 




V.27bis 




not supported 




V.29 




not supported 




no comparable value 




autobauding type 1 (note 16) 


5a 


User rate 


6d 


Fixed network user rate (note 20) 


#5..1 


no comparable value 


#5..1 


FNUR not applicable 




9,6 kbit/s 




9,6 kbit/s 




14,4kbit/s 




14,4 kbit/s 




19,2 kbit/s 




19,2 kbit/s 




28,8 kbit/s 




28,8 kbit/s 




32.0 kbit/s 




32.0 kbit/s (note 27) 




38,4 kbit/s 




38,4 kbit/s 




48 kbit/s 




48,0 kbit/s 




56 kbit/s 




56,0 kbit/s 




no comparable value 




64,0 kbit/s (note 22) 




Modem type 


6d 


Other modem type 




no comparable value (note 21 ) 


#7..6 


No other modem type 




V.34 




V.34 




No comparable field 


6f 


User initiated modification indicator 






#7..5 


(note 1) (note 25) 

User initiated modification not 

required 
User initiated modification upto 1 

TCH/F may be requested 
User initiated modification upto 2 

TCH/F may be requested 
User initiated modification upto 3 

TCH/F may be requested 
User initiated modification upto 4 

TCH/F may be requested 


6 


User information layer 2 protocol 


7 


User information layer 2 protocol (note 




(note 10) 




8) 


#5..1 


Q.921 (1.441) 




no comparable value 




X.25, link level 




not supported 




no comparable value 




ISO 6429, codeset 


7 


User information layer 3 protocol 
(note 10) 








Q.931 (1.451) 




not supported 




X.25, packet level 




not supported 



General notes: 

1) Other ISDN BC parameter values than those listed in the table, if indicated in the BC-IE, will be rejected by 
clearing the call, exception see mapping note 4. 

2) Only the PLMN BC parameter values listed in the table may be generated (comparable values) during a 
mobile-terminated call by mapping the ISDN BC parameter values, exception see (10). 
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3) According to Q.931 (05/98) and 3GPP TS 24.008, respectively, the octets are counted from 1 to n onwards; the 
bit position in a particular octet is indicated by #x..y, with {x,y} = 1..8 (bit 1 is the least and bit 8 the most 
significant bit). 

4) If octets 5 to 5d of the ISDN BC are absent but present in the LLC, the LLC octets should apply for the mapping 
as indicated above. For V.120 interworking (see note 24) these LLC octets shall apply. 

5) If within the ISDN BC the parameters information transfer capability indicates "3,1 kHz audio" and user layer 1 
protocol indicates "G71 1 A-law" or "G.71 1 |i-law" (PCS-1900) but no modem type is available and the HLC 
does not indicate "facsimile group 3", octets 5 to 5d of the LLC, if available, apply for the above mapping 
procedure. 

6) The number of octets which shall be encoded for the PLMN BC-IE must comply to encoding rules in 3GPP 
TS 24.008 and the combination of the different parameter values shall be in accordance to 3GPP TS 27.00L 

Notes regarding particular entries in table 7B: 

1) This PLMN parameter value is inserted according to user rate requirements and network 
capabilities / preferences. 

2) This PLMN parameter value is inserted, if the information transfer capability in ISDN BC is "3,1kHz audio" and 
a comparable modem type is specified. 

3) This PLMN parameter value is inserted, if the information transfer capability is "3,1 kHz audio" and the content 
of the HLC-IE, if any, indicates "facsimile group 2/3", (for details refer to subclause 10.2.2.3 case 3 for HLR 
action and subclause 10.2.2.4 case 5 for VMSC action). Note that via MAP the value "alternate speech/facsimile 
group 3 - starting with speech" shall be used, when TS 61 applies. 

4) When interworking with an ISDN according to ETS 300 102-1, octets 4a and 4b may be present. The values are 
ignored and PLMN values are set according to notes 5 and 9. 

5) This PLMN parameter value is inserted if the comparable ISDN parameter value is missing. 

6) The value of the Intermediate Rate field of the PLMN Bearer Capability information element shall only depend 
on the value of the user rate in the same information element. If the connection element is "transparent", the 
value is 16 kbit/s, if the user rate is 9.6 or 12 kbit/s, and 8 kbit/s otherwise. For any other connection element 
setting the value is 16 kbit/s. 

7) This PLMN BC parameter value is inserted, if the PLMN BC parameter "Information Transfer Capability" 
indicates "Unrestricted digital information", "facsimile group 3" or "alternate speech/facsimile group 3, starting 
with speech". 

8) Where the network indicates "asynchronous" and connection elements "non-transparent", "both, transparent 
preferred" or "both, non-transparent preferred" , then the PLMN BC should be forwarded without parameter user 
information layer 2 protocol, see also (10). 

9) The PLMN parameter value shall be set to "unstructured" where the network indicates connection element 
"transparent". Where the network indicates connection elements "non transparent" "both, transparent preferred" 
or "both, non transparent preferred" the value of the parameter structure shall be set to "SDU Integrity". 

10)Mapping of parameter values of this octet to PLMN BC parameters and values are subject to specific application 
rules, i.e. unless otherwise explicitly stated in an appropriate TS mapping to PLMN BC parameters shall not take 
place. 

1 l)This value shall be used when the value of the PLMN BC parameter "Information Transfer Capability" indicates 
the value "3,1 kHz audio ex PLMN", "facsimile group 3" or "alternate speech/facsimile group 3, starting with 
speech" which is reserved for MAP operations. 

12) The modem encoding of both Q.931 (05/98) and ETS 300 102-1 version 1 shall be accepted and mapped 
according to 3GPP TS 24.008. 

13) Value not used for currently defined bearer services and Teleservices. 

14)NIC is only supported in A/Gb mode for "3,1 kHz Ex PLMN audio" interworking with synchronous data 
transmission. 
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15)Because the required flow control mechanism can not be indicated to the UE (refer to 3GPP TS 27.001), the 
network shall check if the flow control mechanism selected by the UE and indicated in the CALL CONFIRMED 
message suits to the requirements requested by the ISDN terminal adaptor. If there is a mismatch the call shall be 
released in the IWF. 

Because an asymmetric flow control mechanism (with respect to transmitting and receiving side) is not 
supported in the PLMN, the different values of the ISDN BC-IE parameters "flow control on Tx" and "flow 
control on Rx" shall be interpreted in the following way: 

"Flow control on Rx" set to "accepted" matches with "outband flow control", irrespective of the value of the 
parameter "flow control on Tx". 

"Flow control on Rx" set to "not accepted" and "flow control on Tx" set to "not required" matches with 
"inband flow control" and "no flow control". 

where "Flow control on Rx" is set to "not accepted" and "flow control on Tx" to "required" the call shall be 
released by the IWF. 

16) If 3,1 kHz audio interworking "inband negotiation possible" is indicated and the parameter user rate is set to 
"rate is indicated by E bits specified in Recommendation 1.460 or may be negotiated inband" the user rate in the 
PLMN BC-IE shall be set according to a network preferred value. If ISDN-BC parameter modem type is present, 
its value shall be ignored. The PLMN BC parameter modem type shall be set according to the user rate for 
connection element "transparent" and to "autobauding type 1" for connection element "non transparent", "both, 
transparent preferred" or "both, non transparent preferred". If data compression is used, high speed modems, like 
V.32bis, V.34 and/or V.90 may be used in the IWF. Autobauding may also be used to support user rates less than 
9.6 kbit/s towards the PSTN. 

For unrestricted digital interworking the call shall be rejected if these values are indicated. 

If the PLMN-BC parameter modem type indicates "autobauding type 1" or "none", then the PLMN-BC 

parameter other modem type shall be set to "no other modem type". 

17) For the use of NIRR see 3GPP TS 27.001. The VMSC shall set this parameter dependent upon its capabilities 
and preferences. 

18) If compression is supported by the MSC, the value "data compression possible" may be set. Depending on the 
capabilities of the MSC, the user rate value and the intermediate rate value is set to an appropriate value. 

19)Only applicable if the parameter ISDN-BC ITC indicates "3,1 kHz audio" and for "UDI" calls if User Rate > 
"19,2 kbit/s". 

20) The user rate of the PLMN BC is set to the value for the fall-back bearer service. If the user equipment does not 
support the fixed network user rate (i.e. the call confirmation message does not contain the fixed network user 
rate parameter), the network may release the call for a transparent connection element. 

21) The modem type parameter of the PLMN -BC is taken into account, only. 

22) If no LLC is received and the ISDN-BC received consists of octets 1 to 4 only, coded: 

Coding standard: CCITT 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64kbit/s 

the following PLMN -BC parameters, shall be set to: 

fixed network user rate: 64 kbit/s 

connection element: transparent 

bothNT or bothT (If IWF supports PIAFS) 

The other parameters of the PLMN -BC shall be set to values indicating a fall-back service. 

If an LLC indicating UIL1P=X.31 (either explicitly or implicitly by octet 5 missing) is received and the ISDN- 
BC received consists of 1 to 4 only, coded: 

Coding standard: ITU-T 

Information Transfer capability: UDI 
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Transfer mode: circuit 

Information transfer rate: 64kbit/s 

the following PLMN BC parameters, shall be set to: 

fixed network user rate: 64 kbit/s 

connection element: non-transparent 

Synchronous/Asynchronous asynchronous 

all other parameters shall be set according to 3GPP TS 27.001 to indicate FTM. 

If an LLC indicating UIL1P=X.31 (either explicitly or implicitly by octet 5 missing) is received and the ISDN- 
BC received consists of 1 to 4 only, coded: 

Coding standard: ITU-T 

Information Transfer capability: RDI 

Transfer mode: circuit 

Information transfer rate: 64kbit/s 

the following PLMN BC parameters, shall be set to: 

fixed network user rate: 56 kbit/s 

connection element: non-transparent 

Synchronous/Asynchronous asynchronous 

all other parameters shall be set according to 3GPP TS 27.001 to indicate FTM. 

23) When the MSC is directly connected to a restricted 64 kbit/s network, the ISDN BC-IE is coded with an 
ITC = RDI. 

An ISDN BC-IE, as specified in ETR 018 and shown below, shall be taken to indicate that interworking with an 
indirectly connected restricted 64 kbit/s network is required: 

Coding standard: CCITT 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

User information layer 1 protocol: V.110/X.30 

Synchronous/Asynchronous: synchronous 

Negotiation: In-band negotiation not possible 

User rate: 56 kbit/s 

In this case the PLMN BC parameter Information Transfer Capability is set to „Other ITC" and Other ITC 
parameter is set to „restricted digital". If ISDN LLC exists, all the corresponding fields in the PLMN BC shall be 
derived from the ISDN LLC. Otherwise, the corresponding fields in the PLMN BC shall be derived from the 
ISDN BC. In the above both case. Connection element is set as follows. 

Connection element: transparent 

bothNT or bothT (If IWF supports FTM) and LLC does not indicate 
User information layer 1 protocol = 'X.31 flag stuffing') 
non-transparent (if IWF supports FTM and LLC indicates 
User information layer 1 protocol = 'X.31 flag stuffing') 



24) V. 120 interworking is required if the ISDN LLC parameter User Information Layer 1 Protocol is set to „V.120". 
In this case the PLMN BC parameter Rate Adaptation is set to „Other rate adaptation" and Other Rate 
Adaptation parameter is set to „V.120". All the corresponding fields in the PLMN BC shall be derived from the 
ISDN LLC. 

25) This parameter is only included for non-transparent multislot connections. 

26) This value was used by services defined for former PLMN releases and does not need to be supported. 
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27) Following BC parameters in SETUP message shall be set to: 

Fixed network user rate 32 kbit/s 

Connection element transparent (for multimedia) 

bothNT or bothT (If IWF supports PIAFS, UTRAN lu mode only) 

28) UILIP is set to "H.221 & H.242" or "H.223 & H.245" by H.324/I. If UILIP is set to "H.221 and H.242", this 
should be mapped to "H.223 & H.245". 

29) In lu mode, if the User Rate of the ISDN BC is less than 9,6 kbit/s and the Connection Element is mapped to 
"NT", then FNUR is fixed to 9,6 kbit/s. 



10.2.2.7 Creation of Backup Bearer Capability Information Element 

If the VMSC is not able to send a PLMN BC to the MS/UE for mobile terminated calls, it may include all available 
information in the Backup BC information element (Backup BC IE) of the call set-up message. 

In the following table 7C the comparison is drawn between parameters in the ISDN call set up request message and that 
of the PLMN call set up request message. In some cases no comparable values are available and these will be marked as 
such. In some cases it is not necessary to support a particular option, and in this case those parameters will be annotated 
appropriately. 

The PLMN parameters and values shall as in 3GPP TS 24.008 in combination as in 3GPP TS 27.00L The ISDN 
parameters and values are as in Q.931 (05/98). 



£75/ 



3GPP TS 29.007 version 9.1.0 Release 9 



61 



ETSI TS 129 007 V9.1.0 (2010-10) 



Table 7C: Setting of parameters in Backup BC IE 



Octet 


ISDN BC / LLC parameter value 


Octet 


BACKUP BC parameter value 


1 


Bearer Capability lEI 


1 


Bearer Capability lEI 


2 


Length of BC contents 


2 


Length of BC contents 




no comparable field 


3 


Radio channel requirement 






#7..6 


full rate channel (these bits are spare) 


3 


Coding standard 


3 


Coding standard 


#7..6 


CCITT standardized coding 


#5 


GSM standardized coding 


3 


Information transfer capability 


3 


Information transfer capability 


#5..1 


speech 


#3..1 


speech 




unrestricted digital 




unrestricted digital 




3,1 kHz audio 




3,1 kHz audio ex PLIVIN (note2) 




no comparable value 




facsimile group 3 (note 3) 




no comparable value 




other ITG (see octet 5a) 




7 kHz audio 




not supported 




video 




not supported 


5a 


Other ITC 




(note 23) 


#7..6 


restricted digital 


4 


Transfer mode 


3 


Transfer mode 


#7..6 


circuit mode 


#4 


circuit mode 




packet mode 




not supported 




no comparable field 


4 


Compression (note 18) 






#7 


data compression not possible 


4a 


no comparable field (note 4) 


(4)4 


Structure (note 9) 


#7..5 




#6..5 


SDU integrity 
unstructured 


4a 


no comparable field (note 4) 


4 


Configuration 


#4.. 3 




#3 


point-to-point (note 5) 




no comparable field 


4 


NIRR (note 17) 






#2 


No meaning 


4a 


no comparable field (note 4) 


4 


Establishment 


#2..1 




#1 


demand (note 5) 


5 


User information layer 1 protocol 


5 


Rate adaption 


#5..1 


no comparable value 


#5.. 4 


no rate adaption (note 1 1 ) 




CCITT V.1 10, 1.460 /X.30 




V.1 10, I.460/X.30 rate adaption 




G.711 A-law 




no comparable value 




CCITT X.31 flag stuffing. 




not supported. 




no comparable value 




other rate adaption (see octet 5a) 


5a 


Other rate adaptation 




H.221 & H.242 (note 28) 


#5.. 4 


H.223 & H.245 




H.223 & H.245 




H.223 & H.245 




no comparable field 


5 


Signalling access protocol 






#3..1 


1.440/1.450 






6 


User information layer 1 protocol 




any of the above values 


#5..2 


default layer 1 protocol 


5a 


Synchronous / asynchronous (note 30) 


6 


Synchronous/asynchronous 


#7 


synchronous 


#1 


synchronous 




asynchronous 




asynchronous 


5a 


Negotiation 


6a 


Negotiation 


#6 


not possible 


#6 


not possible (note 5) 




inband neg, possible (note 16) 




no comparable value 


5a 


User rate 


6a 


User rate (note 29) 


#5..1 


0,3 kbit/s 


#4..1 


0,3 kbit/s 




1 ,2 kbit/s 




1 ,2 kbit/s 




2,4 kbit/s 




2,4 kbit/s 




4,8 kbit/s 




4,8 kbit/s 




9,6 kbit/s 




9,6 kbit/s 




1 2 kbit/s 




12 kbit/s (note 13) 




rate is indicated by Ebit as specified in rec. 




(note 16) 




1.460 








0,6 kbit/s 




not supported 




3,6 kbit/s 




not supported 




7,2 kbit/s 




not supported 




8 kbit/s 




not supported 




14,4 kbit/s 




(note 20) 




1 6 kbit/s 




not supported 
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Octet 


ISDN BC / LLC parameter value 


Octet 


BACKUP BC parameter value 




19.2 kbit/s 




(note 20) 




28.8 kbit/s 




(note 20) 




32 kbit/s 




(note 20) 




38.4 kbit/s 




(note 20) 




48 kbit/s 




(note 20) 




56 kbit/s 




(note 20) 




57.6 kbit/s 




not supported 




0,1345 kbit/s 




not supported 




0,1 kbit/s 




not supported 




75 bit/s / 1 ,2 kbit/s 




not supported 




1 ,2 kbit/s / 75 bit/s 




not supported 




0,1 10 kbit/s 




not supported 




0,2 kbit/s 




not supported 




no comparable value 




unknown 


5b 


Intermediate rate 


6b 


Intermediate rate (note 6) 


#7..6 


any value 


#7..6 


8 kbit/s 
1 6 kbit/s 


5b 


NIC on Tx (note 14) 


6b 


NIC on Tx 


#5 


does not require 


#5 


does not require (note 5) 




requires 




requires (note 13) 


5b 


NIC on Rx (note 14) 


6b 


NIC on Rx 


#4 


cannot accept 


#4 


cannot accept (note 5) 




can accept 




can accept (note 13) 


5c 


Number of stop bits 


6a 


Number of stop bits 


#7..6 


1 bit 


#7 


1 bit (note 5) 




2 bits 




2 bits 




not used 




no comparable value 




1 .5 bits 




not supported 


5c 


Number of data bits 


6a 


Number of data bits 


#5.. 4 


7 bits 


#5 


7 bits 




8 bits 




8 bits (note 5) 




not used 




no comparable value 




5 bits 




not supported 


5c 


Parity information 


6b 


Parity information 


#3..1 


odd 


#3..1 


odd 




even 




even 




none 




none (note 5) 




forced to 




forced to 




forced to 1 




forced to 1 






6c 


Connection element (note 1) 




no comparable field 


#7..6 


transparent 
non-transparent (RLP) 
both, transp. preferred 
both, non-transp preferred 


5d 


Duplex mode 


4 


Duplex mode 


#7 


half duplex 


#4 


half duplex (note 13) 




full duplex 




full duplex (note 5) 


5d 


Modem type 


6c 


Modem type (note 12) 


#6..1 


reserved 


#5..1 


none (note 7) 




V.21 




V.21 




V.22 




V.22 




V.22bis 




V.22bis 




V.23 




not supported 




V.26ter 




V.26ter 




V.32 




V.32 




V.26 




not supported 




V.26bis 




not supported 




V.27 




not supported 




V.27bis 




not supported 




V.29 




not supported 




no comparable value 




autobauding type 1 (note 16) 


5a 


User rate 


6d 


Fixed network user rate (note 20) 


#5..1 


no comparable value 


#5..1 


FNUR not applicable /unknown 




9,6 kbit/s 




9,6 kbit/s 




14,4 kbit/s 




14,4 kbit/s 




19,2 kbit/s 




19,2 kbit/s 
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Octet 


ISDN BC / LLC parameter value 


Octet 


BACKUP BC parameter value 




28,8 kbit/s 

32.0 kbit/s 

38,4 kbit/s 

48 kbit/s 

56 kbit/s 

no comparable value 




28,8 kbit/s 

32.0 kbit/s (note 27) 

38,4 kbit/s 

48,0 kbit/s 

56,0 kbit/s 

64,0 kbit/s (note 22) 




Modem type 

no comparable value (note 21 ) 
V.34 


6d 
#7..6 


Other modem type 

No other modem type 
V.34 




no comparable field 


6e 
#7..6 


Acceptable channel codings 

spare 




no comparable field 


6e 

#5..1 


Maximum number of traffic channels 

spare 




No comparable field 


6f 
#7..5 


User initiated modification indicator 
(note 1) (note 25) 

User initiated modification not 

required 
User initiated modification upto 1 

TCH/F may be requested 
User initiated modification upto 2 

TCH/F may be requested 
User initiated modification upto 3 

TCH/F may be requested 
User initiated modification upto 4 

TCH/F may be requested 




no comparable field 


6f 
#4..1 


Wanted air interface user rate 

spare 




no comparable field 


6g 

#7..5 


Acceptable channel codings extended 

spare 




no comparable field 


6g 

#4.. 3 


Asymmetry indications 

spare 


6 

#5..1 


User information layer 2 protocol 
(note 10) 

Q.921 (1.441) 
X.25, link level 
no comparable value 
no comparable value 


7 


User information layer 2 protocol (note 
8) 

no comparable value 
not supported 
ISO 6429, codeset 
unknown 



General notes: 

1) Only the PLMN BC parameter values listed in the table may be generated (comparable values) during a 
mobile-terminated call by mapping the ISDN BC parameter values, exception see (10). 

2) According to Q.931 (05/98) and 3GPP TS 24.008, respectively, the octets are counted from 1 to n onwards; the 
bit position in a particular octet is indicated by #x..y, with {x,y} = 1..8 (bit 1 is the least and bit 8 the most 
significant bit). 

3) If octets of the ISDN BC are absent but present in the LLC, the LLC octets should apply for the mapping. 

4) The number of octets which shall be encoded for the Backup BC-IE must comply to encoding rules in 3GPP 

TS 24.008 and the combination of the different parameter values shall be in accordance to 3GPP TS 27.001 with 
the modification that some parameters may be absent, if a whole octet is absent, and some parameters may get 
values defined for the Backup BC only. However, parameter values that are valid for both the PLMN BC and the 
Backup BC shall not be in contradiction to 3GPP TS 27.001. 

Notes regarding particular entries in table 7C: 

1) This PLMN parameter value is inserted according to user rate requirements and network 
capabilities / preferences. 

2) This PLMN parameter value is inserted, if the information transfer capability in ISDN BC is "3,1kHz audio" and 
a comparable modem type is specified. 
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3) This PLMN parameter value is inserted, if the information transfer capability is "3,1 kHz audio" and the content 
of the HLC-IE, if any, indicates "facsimile group 2/3", (for details refer to subclause 10.2.2.3 case 3 for HLR 
action and subclause 10.2.2.4 case 5 for VMSC action). 

4) When interworking with an ISDN according to ETS 300 102-1, octets 4a and 4b may be present. The values are 
ignored and PLMN values are set according to notes 5 and 9. 

5) This PLMN parameter value is inserted if the comparable ISDN parameter value is missing. 

6) The value of the Intermediate Rate field of the PLMN Bearer Capability information element shall only depend 
on the value of the user rate in the same information element. If the connection element is "transparent", the 
value is 16 kbit/s, if the user rate is 9.6 or 12 kbit/s, and 8 kbit/s otherwise. For any other connection element 
setting the value is 16 kbit/s. If the user rate value is "unknown" any value can be used, it has to be ignored by 
theUE 

7) This PLMN BC parameter value is inserted, if the PLMN BC parameter "Information Transfer Capability" 
indicates "Unrestricted digital information "or "facsimile group 3". 

8) Where the network indicates "asynchronous" and connection elements "non-transparent", "both, transparent 
preferred" or "both, non-transparent preferred" , then the PLMN BC should be forwarded without parameter user 
information layer 2 protocol, see also (10). 

9) The PLMN parameter value shall be set to "unstructured" where the network indicates connection element 
"transparent". Where the network indicates connection elements "non transparent" "both, transparent preferred" 
or "both, non transparent preferred" the value of the parameter structure shall be set to "SDU Integrity". 

10)Mapping of parameter values of this octet to PLMN BC parameters and values are subject to specific application 
rules, i.e. unless otherwise explicitly stated in an appropriate TS mapping to PLMN BC parameters shall not take 
place. 

1 l)This value shall be used when the value of the PLMN BC parameter "Information Transfer Capability" indicates 
the value "3,1 kHz audio ex PLMN" or "facsimile group 3". 

12) The modem encoding of both Q.931 (05/98) and ETS 300 102-1 version 1 shall be accepted and mapped 
according to 3GPP TS 24.008. 

13) Value not used for currently defined bearer services and Teleservices. 

14) NIC is only supported in A/Gb mode for "3,1 kHz Ex PLMN audio" interworking with synchronous data 
transmission. 

15) void. 

16) If 3,1 kHz audio interworking "inband negotiation possible" is indicated and the parameter user rate is set to 
"rate is indicated by E bits specified in Recommendation 1.460 or may be negotiated inband" the user rate in the 
PLMN BC-IE shall be set according to a network preferred value. If ISDN-BC parameter modem type is present, 
its value shall be ignored. The PLMN-BC parameter modem type shall be set according to the user rate for 
connection element "transparent" and to "autobauding type 1" for connection element "non transparent", "both, 
transparent preferred" or "both, non transparent preferred". If data compression is used, high speed modems, like 
V.32bis, V.34 and/or V.90 may be used in the IWF. Autobauding may also be used to support user rates less than 
9.6 kbit/s towards the PSTN. 

For unrestricted digital interworking the call shall be rejected if these values are indicated. 

If the PLMN-BC parameter modem type indicates "autobauding type 1" or "none", then the PLMN-BC 

parameter other modem type shall be set to "no other modem type". 

17) An indication of NIRR is not possible in the Backup BC because it has to be negotiated by parameter values in 
the PLMN BC. 

18) An indication of compression is not possible in the Backup BC because it has to be negotiated by parameter 
values in the PLMN BC. 

19) void. 
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20) The user rate of the PLMN BC is set to the value for the fall-back bearer service. If the user equipment does not 
support the fixed network user rate (i.e. the call confirmation message does not contain the fixed network user 
rate parameter), the network may release the call for a transparent connection element. 

21) The modem type parameter of the PLMN -BC is taken into account, only. 

22) If no LLC is received and the ISDN-BC received consists of octets 1 to 4 only, coded: 

Coding standard: CCITT 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64kbit/s 

the following PLMN -BC parameters, shall be set to: 

fixed network user rate: 64 kbit/s 

connection element: transparent 

bothNT or bothT (If IWF supports FTM) 

The other parameters of the PLMN -BC shall be set to values indicating a fall-back service. 

23) When the MSC is directly connected to a restricted 64 kbit/s network, the ISDN BC-IE is coded with an 
ITC = RDI. 

An ISDN BC-IE, as specified in ETR 018 and shown below, shall be taken to indicate that interworking with an 
indirectly connected restricted 64 kbit/s network is required: 

Coding standard: CCITT 

Information Transfer capability: UDI 

Transfer mode: circuit 

Information transfer rate: 64 kbit/s 

User information layer 1 protocol: V.l 10/X.30 

Synchronous/Asynchronous: synchronous 

Negotiation: In-band negotiation not possible 

User rate: 56 kbit/s 

In this case the PLMN BC parameter Information Transfer Capability is set to „Other ITC" and Other ITC 
parameter is set to „restricted digital". If ISDN LLC exists, all the corresponding fields in the PLMN BC shall be 
derived from the ISDN LLC. Otherwise, the corresponding fields in the PLMN BC shall be derived from the 
ISDN BC. In the above both case. Connection element is set as follows. 

Connection element: transparent 

bothNT or bothT (If IWF supports FTM) 

24) Void. 

25) This parameter is only included for non-transparent multislot connections. 

26) This value was used by services defined for former PLMN releases and does not need to be supported. 

27) Following BC parameters in SETUP message shall be set to: 

Fixed network user rate 32 kbit/s 

Connection element transparent (for multimedia) 

28) UILIP is set to "H.221 & H.242" or "H.223 & H.245" by H.324/I. If UILIP is set to "H.221 and H.242", this 
should be mapped to "H.223 & H.245". 

29) In lu mode, if the User Rate of the ISDN BC is less than 9,6 kbit/s and the Connection Element is mapped to 
"NT", then FNUR is fixed to 9,6 kbit/s. 

30) If this parameter value is missing, the Backup BC shall not contain parameter octets 6 and higher. 
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1 0.2.3 Transparent service support 

The protocol stacks for transparent services are specified in 3GPP TS 43.010 and in Clause 1 la. 3. 

In lu mode, the transparent services are based in the lu User Plane protocol specified in 3GPP TS 25.415. 

In A/Gb mode identifies the rate adaptation scheme shall be utilized on the RAN to MSC link as identified in 3GPP TS 
48.020. The transcoding function will generate the 64 kbit/s rate adapted format utilizing the 8 and 16 kbit/s 
intermediate data rates. The MSC - MSC/IWF will utilize the same rate adaptation scheme as that indicated in 3GPP TS 
48.020, i.e. adapted to 64 kbit/s. 

1 0.2.3.1 Structure of the MSC/IWF for lu mode 

The transmission towards the RNC is based on AAL2. The lu UP is used in the transparent mode. 

3.1kHz 



luUP 



AAL2 



ATM 




MODEM 



CODEC 



audio 



ISDN TA 

function 



64 kbit/s unrestricted 



or 56 kbit/s restricted 
64 kbit/s unrestricted 



or 56 kbit/s restricted 
Figure 10: Structure of the MSC/IWF (transparent) 



1 0.2.3.2 Structure of the MSC/IWF for A/Gb mode 

When interworking to the unrestricted digital bearer service rate adaptation according to ITU-T Recommendation V.llO 
will be necessary within the MSC/IWF. For multislot, TCH/F14.4 or EDGE operations MSC/IWF shall adapt the data 
stream as defined in 3GPP TS 44.021 and 3GPP TS 48.020. 

NOTE: From the perspective of MSC/IWF, a TCH/F28.8 EDGE configuration is identical to a multislot 
2XTCH/F14.4 configuration. 

When interworking to the 3,1 kHz audio service, then the same process as for the PSTN case is necessary 
(section 9.2.3.2). 
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10.2.3.3 



Figure 11 : Structure of the MSC/IWF (transparent) 

Mapping of signalling UE/MSC/IWF to modem or ISDN (V.1 1 0) TA-function 
interface requirements 



For the 3,1 kHz audio interworking case see subclause 9.2.3.3. 

Status bits SA, SB and X can be used to convey channel control information associated with the data bits in the data 
transfer state. Table 8 shows the mapping scheme between the V.24 circuit numbers corresponding to the V-series DCE 
functions and the status bits for the transparent mode. It also shows how the unused status bits should be handled. It is 
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derived from the General Mapping scheme described in annex B. A binary corresponds to the ON condition, a binary 
1 to the OFF condition. 

The transport of these status bits by the various channel codings is described in 3GPP TS 44.021 and 48.020 for A/Gb 
mode. For lu mode refer to 3GPP Clause 11a. 



NOTE 



Although the interface to the ISDN TA function is described in terms of V.24 interchange circuit 
functions, this does not imply that such circuits need to be physically realised. 

Table 8: Mapping scheme at the IWF for the transparent mode 



Mapping 
direction: UE to IWF 


Mapping 
direction: IWF to UE 


Signal at IWF ISDN TA 

interface or condition 

within the IWF 


always ON (note 1 ) 




CT105 




to status bit X 


CT106 




not mapped (note 5) 


CT107 


not mapped (note 6) 




CT108 




to status bit SB 


CT109 


always ON (note 2) 




CT133 


from status bit SA (note 3) 




ignored by IWF 


from status bit SB (note 1 ) 




ignored by IWF 


from status bit X (note 4) 




ignored by IWF 




to status bit SA (note 3) 


always ON 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (annex B), 
could be used to carry CT 1 05 from the mobile DTE to the ISDN TA 
function in the IWF. However, CT 105 should always be ON at the DTE 
interface in the data transfer state since only duplex operation is 
supported. Also, many DTEs use the connector pin assigned to CT 105 
for CT 133. Therefore, CT 105 shall always be set to ON at the IWF ISDN 
TA function during the data transfer state. 

NOTE 2: CT 133 is not mapped since there is no flow control in transparent mode. 

NOTE 3: The SA bits in both directions are available only with certain channel 
codings. Therefore, for maximum compatibility, they should not be 
mapped. 

NOTE 4: The X bit towards the IWF is not mapped since there is no flow control in 
transparent mode. 

NOTE 5: CT 1 07 is not used by the IWF. 

NOTE 6: CT 108 is used in the call setup and answering processes. 



1 0.2.3.4 Establishment of end-to-end terminal synchronizations 

Prior to exposing the traffic channel of a PLMN connection to transmission of user data, the controlling entities of the 
connection shall assure of the availability of the traffic channel. This is done by a so called synchronizations process: 

starting on the indication of "physical connection established" resulting from the PLMN -inherent outband 
signalling procedure This indication is given: 

- for MOC: on sending the CONNECT message; 

- for MTC: on sending the CONNECT ACKNOWLEDGE message; 

for mobile initiated in-call modification: on sending the MODIFY COMPLETE message (which is sent after 
reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message); and 

- for network initiated in-call modification: on reception of the ASSIGNMENT COMPLETE or RAB 
ASSIGNMENT RESPONSE message; 

ending by indicating the successful execution of this process to the controlling entity, which then takes care of 
the further use of the inband information (data, status). 

Network interworking within an MSC/IWF is concerned with the terminating side (to the UE) and the transit side (to 
the fixed network) of a connection. Both sides shall be treated individually related to the synchronizations process. 
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1 0.2.3.4.1 Terminating side (towards the UE) 

10.2.3.4.1 .1 Traffic channel types TCH/F4.8 and TCH/F9.6 in A/Gb mode 

With respect to the terminating side the procedure is as follows: 

sending of synchronizations pattern 1/OFF (all data bits "I'Vall status bits "OFF") to the UE using the RA1/RA2 
rate adaptation function. In multislot transparent operation, the synchronisation pattern sent is 1/OFF with the 
exception of the bit positions SI, first X, S3, and S4 which contain the substream number and multiframe 
alignment pattern (see 3GPP TS 44.021); 

searching for detection of the synchronizations pattern from the UE within valid V. 110 frames, and in multislot 
operation, also searching for the multiframe aUgnment pattern "0000 1001 01 10 01 1 1 1 100 01 10 1 1 10 101" (see 
3GPP TS 44.021) in bit position S4 and substream numbers in bit positions SI, first X, and S3. This implies that 
the El, E2 and E3 bit of the V. 1 10 frame shall be checked for the appropriate user rate in order to distinguish the 
synchronization pattern from the RAN idle data frame. 

Timer T (= 500 ms) is started for each of the allocated traffic channel(s) of the call on receipt of the 
synchronizations pattern from the UE. 

When the frame alignment pattern and, in case of multislot operation, the multiframe alignment pattern have 
been recognized as a steady state, the MSC/IWF continues sending the synchronizations patterns to the UE until 
a timer T expires. 

1 0.2.3.4.1 .2 Traffic cinannel type TCH/F14.4 for A/Gb mode 

With respect to the terminating side the procedure is as follows: 

Sending A-TRAU frames with the data rate set in the bits C1-C4 (TS 48.020) and data bits set to one, sending 
the multiframe structure with the alignment pattern (bit Ml) and with the status bits OFF (bit M2) and, in a 
multislot case, sending substream numbers (bit M2). 

- Searching for the detection of the multiframe alignment pattern ,,0000 1001 01 10 01 1 1 1 100 01 10 1 1 10 101 " 
(TS 44.021) in the bit Ml and, in a multislot case, searching for substream numbers in the bit M2. (Any 5 bit 
sequence in the multiframe alignment pattern is unique, i.e. the multiframe alignment can take place by 
recognition of five successive Ml bits). 

Timer T (= 500 ms) is started for each of the allocated traffic channel(s) of the call on receipt of the 
synchronizations pattern from the UE. 

When the frame alignment pattern and the multiframe alignment pattern have been recognized as a steady state, 
the MSC/IWF continues sending the synchronizations patterns to the UE until a timer T expires. 

10.2.3.4.1.3 User Plane for lu mode 

The procedures are the same as for the modem case, but, depending on implementation, the IWF may through connect 
before the fixed network leg has been synchronised. 

1 0.2.3.4.2 Transit side (towards the fixed network). 

In case of interworking to the ISDN "3,1 kHz audio" bearer service the synchronization process is as for the PSTN 
interworking case (see subclause 9.2.3.4.2). 

In case of V.l 10 interworking to the ISDN unrestricted digital bearer service the following synchronization process 
shall be performed. 

The interchange circuits towards the V.l 10 ISDN TA function are held in the OFF condition until timer T 
expires, when they are switched to ON. 
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From this time, after the expiration of the timer T of every allocated traffic channel, the information on CT106 
and CT109 from the IWF V.l 10 ISDN TA function are directly mapped to the X and SB bits, respectively, 
towards the UE. For TCH/F14.4 the X and SB bits are mapped to the M2 multiframe bits according to 3GPP TS 
44.021 . Circuit 108 to the selected V. 1 10 ISDN TA function associated with the connection will be switched 
from the "OFF" to "ON" condition, thus initiating the synchronization process on the fixed network according to 
ITU-T Recommendation V. 1 10. The IWF is allowed to map CT 104 to the data bits sent towards the UE and to 
map data bits received from the UE to CT 103. 

1 0.2.3.5 Network independent Clocking (NIC) 

Due to the incompatibility between the ISDN and the PLMN requirements for NIC interworking is not provided 
between these two formats. As such no NIC function is required in providing interworking to the ISDN. In this case, the 
IWF shall disregard the value of bits E4, E5, E6 and E7 in the data transmission phase. 

1 0.2.4 Non-transparent service support 

The protocol stacks for non-transparent services are specified in 3GPP TS 43.010 and in Clause 1 la. 2. Both of the 
systems use the Radio Link Protocol (RLP) specified in 3GPP TS 24.022. 

In lu mode, the non-transparent services are based in the lu User Plane protocol specified in 3GPP TS 25.415. 

In A/Gb mode the corresponding necessary support concerning the rate adaptation scheme shall be utilized on the 
RAN-MSC link as identified in 3GPP TS 48.020. 

For the non-transparent service support the MSC/IWF will select the modem and speed based on the Compatibility 
information contained in either the call set-up or call confirmed message, reference subclauses 9.2.1 and 9.2.2. Where 
the Modem Type indicated is autobauding type 1, the MSC/IWF may select any speed and modem type according to 
what it can negotiate with the remote modem. In this case User Rate and Fixed Network User Rate, if present, has no 
meaning. 



10.2.4.1 



Structure of the MSC/IWF for lu mode 



The transmission towards the RNC is based on AAL2. The lu UP is used in the support mode. The RLP/L2R extends to 
the UE. 




3.1 kHz 
audio 



64 kbit/s unrestricted 
or 56 kbit/s restricted^ 

1) not applicable for PIAFS 



Figure 12: Structure of the MSC/IWF (non-transparent) 



10.2.4.2 



Structure of the MSC/IWF for A/Gb mode 



The rate adaptation process will be the same as for the transparent case. , except that a TCH/F43.2 channel coding is 
also supported. From MSC/IWF's perspective a TCH/F43.2 EDGE configuration is identical to a multislot 
3XTCH/F14.4 configuration. 

3GPP TS 43.010 identifies the protocol layer structure for the non-transparent case, the MSC/IWF provides the inverse 
of the action in the UE terminal adaptation function. For a multislot configuration refer to 3GPP TS 43.010. 

The V.l 10, V.120 and PIAFS ISDN TA (terminal adapter) functions provide the same functionality and operational 
behaviour as fixed ISDN terminal adapters that conform to the corresponding ITU-T Recommendations (V.l 10 or 
V.120). 
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Figure 13: Structure of the MSC/IWF (non-transparent) 



10.2.4.3 



Re-constitution of user data 



3GPP TS 24.022 refers to the frame of user data in the radio link protocol. The layer 2 relay functions in the UE and the 
MSC/IWF (identified in 3GPP TS 43.010 and 3GPP TS 23.202 [90]) contain the mechanism for packing and unpacking 
the user data into the L2R protocol data units. 

1 0.2.4.4 Layer 2 relay functionality 

Specific functionality is required on the L2R dependant upon the service which is being requested to be supported. The 
selection of the appropriate L2R function will be determined by the MSC/IWF on the basis of the bearer capability 
information signalled in the call set-up request, or call confirmation message. The prime information element being 
transparent or non transparent service indication. In addition the particular L2R function - type of protocol to be 
terminated and mode of flow control to be applied (see appropriate subclauses in 3GPP TS 27 series) - will be selected 
on the basis of the user's layer 2 indication. 

The specific interaction between the L2R function and the RLP function and the L2R frame structure will be the same 
as that detailed in the Annex to the appropriate 3GPP TS 27 series. 

10.2.4.5 In band signalling mapping flow control 

This entails the L2R function providing the means of controlling and responding to flow control function of the modem 
(or in the rate adapted frame) plus any synchronizations requirements related to flow control. For asynchronous services 
a specific rule applies for flow control (see 3GPP TS 27.001). 

In case of interworking to the ISDN "3,1kHz audio" bearer service the flow control process is as for the PSTN 
interworking case (see subclause 9.2.4.5). In case of interworking to the ISDN unrestricted digital bearer service the 
following procedures apply: 

The flow control function chosen will be dependent upon the availability of the "user information layer 2" information 
element of the PLMN BC and if available its value. 

For V. 110 interworking, outband flow control will be by means of the "X" bit in the V. 1 10 frame to the ISDN. 

For V.120 interworking, outband flow control shall be as follows. In Multiple frame acknowledged mode the functions 
of the data link control sublayer (send RNR or withhold update of the sequence state variable V(R)) shall be used. In 
Unacknowledged mode the RR bit in the Control State octet shall be used. 

For PIAFS interworking, outband flow control shall be as follows. The functions of the data link control sublayer 
(withhold update of the frame number) shall be used. 
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If flow control is provided irrespective of the type used, the L2R function shall: 

a) provide immediate indication of flow control to the fixed network on receipt of flow control request from the 
UE; and/or 

b) provide immediate indication of flow control to the UE on receipt of flow control request from the fixed network 
i.e. in the next available L2R status octet to be transmitted. 

Where in band (X-on/X-off) flow control is in use, then the X-on/X-off characters will not be passed across the radio 
interface. 

If no flow control is provided the involved end systems are responsible for performing in-band flow control on their 
own by taking into account the buffer capacity of the MSC/IWF as stated below. 

1 0.2.4.5.1 Conditions requiring flow control - if flow control is provided - towards the fixed 
network 

The L2R function will initiate flow control in the following circumstances: 

1) the transmit buffer to the radio side reaches a preset threshold (BACK PRESSURE); 

2) the L2R function receives a "flow control active" indication. 

On removal of buffer congestion or receipt of L2R "flow control inactive" the flow control will be removed. 

No flow initiation/removal will take place at the L2R function and loss of data may occur, if no flow control is 
provided. 

1 0.2.4.5.2 Conditions requiring flow control towards the UE 

The L2R function will transmit to the UE a "flow control active indication", if flow control is provided, in the following 
circumstances: 

1) if the receive buffer from the radio side reaches a preset threshold (BACK PRESSURE); 

2) if a flow control indication is received from the fixed network customer. On receipt of this flow control 
indication, transmission of data from the receive buffers towards the fixed network terminal is halted. 

On removal of the buffer congestion or fixed network flow control indication, the L2R function will send a "flow 
control inactive" indication towards the UE. In addition, for the fixed network indication, transmission of data from the 
receive buffers will be restarted. 

If no flow control is provided at the L2R function, no flow control initiation/removal will take place by the MSC/IWF. 
Data might be lost without any indication by the MSC/IWF to the end systems involved. 

10.2.4.6 Data buffers 

1 0.2.4.6.1 Transmit buffers (towards UE) 

Incoming data from the fixed network customer shall be buffered such that if the MSC/IWF is unable to transfer data 
over the radio path the data is not lost. 

The buffer shall be capable of holding the data. Its size is up to the implementers. When the buffer is half full flow 
control towards the fixed network shall be initiated if flow control is provided as per subclause 10.2.4.5.1. 

1 0.2.4.6.2 Receive buffers (from UE) 

Incoming data from the UE is buffered such that if the fixed network terminal is unable to accept the data then it is not 
lost. 

The buffer shall be capable of holding the data. Its size is up to the implementers. When the buffer becomes half full, 
the L2R function will send a "flow control active" indication towards the UE if flow control is provided at the L2R 
function, as per subclause 10.2.4.5.2. 
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10.2.4.7 BREAK Indication 

The BREAK indication is managed as detailed in subclause 9.2.4.7. 

When V.120 rate adaptation is being used in protocol sensitive asynchronous mode on the ISDN, the L2R break 
condition shall map on to the BR bit of the V.120 header octet. 

1 0.2.4.8 Signalling mapping of modem or ISDN (V.1 1 0, V.1 20 or PIAFS) TA-function 
status information 



Status information is carried between the modem or ISDN (V.llO, V.120or PIAFS) TA-function in the IWF and the 
terminal adaption function in the UE by the L2R function. The L2RCOP entity transfers interface status information 
between L2Rs via the status octets SA, SB and X in L2RCOP-PDUs (3GPP TS 27.002). Table 9 shows the mapping 
scheme between the V.24 circuit numbers corresponding to the V-series DCE functions and the status bits for the non- 
transparent mode. It also shows how the unused status bits should be handled. It is derived from the General Mapping 
scheme described in annex B. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

NOTE. Although the interface to the ISDN TA function is described in terms of V.24 interchange circuit 
functions, this does not imply that such circuits need to be physically realised. 

Table 9: Mapping scheme at the IWF for the non-transparent mode 



Mapping 
direction: UEtolWF 


Mapping 
direction: IWF to UE 


Signal at IWF ISDN TA 

interface or condition within 

the IWF 


always ON (note 1 ) 




CT105 




to status bit X (notes 4, 7) 


CT 106 (note 7) 




not mapped (note 5) 


CT107 


not mapped (note 6) 




CT108 




to status bit SB 


CT109 


from status bit X (note 8) 




CT 133 (notes 3, 8) 


from status bit SA (note 2) 




ignored by IWF 


from status bit SB (note 1 ) 




ignored by IWF 




to status bit SA (note 2) 


always ON 


NOTE 1 : The SB bit towards the IWF, according to the General Mapping (annex B), could be 

used to carry CT 1 05 from the mobile DTE to the ISDN TA function in the IWF. 

However, CT 105 should always be ON at the mobile DTE interface in the data 

transfer state since only duplex operation is supported. Also, many DTEs use the 

connector pin assigned to CT 105 for CT 133. Therefore, CT 105 shall always be set 

to ON at the ISDN TA function during the data transfer state. 
NOTE 2: The SA bits (both directions) are not mapped since CTs 107 and 108 are handled 

locally (notes 5, 6). 
NOTE 3: The condition of CT 133 (or other flow control mechanism) may also be affected by 

the state of the L2R transmit buffer (towards the UE) in the IWF and the state of RLP 

(RR/RNR). 
NOTE 4: The condition of status bit X towards the UE may also be affected by the state of the 

L2R receive buffer in the IWF (from the UE). 
NOTE 5: CT 1 07 is not used by the IWF. 

NOTE 6: CT 108 is used in the call setup and answering processes. 
NOTE 7: For inband flow control, CT 1 06 is not mapped and the status bit X towards the UE is 

controlled by the reception of XON and XOFF characters from the ISDN TA function. 
NOTE 8: For inband flow control, changes in the condition of the status bit X from the UE 

result in the sending of XON or XOFF to the ISDN TA function. CT 133 is always set 

to ON. 



1 0.2.4.9 Support of out-band flow control 

Out-band flow control in the case of V.llO rate adaption requires V.llO TA to TA "end-to-end flow control" as defined 
therein. If this functionality is requested by UE but cannot be supported by the MSC/IWF for any reason (refer also to 
note 15 of table 7B) the call pending shall be released. 
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For V.120 interworking, outband flow control shall be as follows. In Multiple frame acknowledged mode the functions 
of the data link control sublayer (send RNR or withhold update of the sequence state variable V(R)) shall be used. In 
Unacknowledged mode the RR bit in the Control State octet shall be used. 

10.2.4.10 Synchronizations 

In case of interworking to the ISDN "3,1kHz audio" bearer service the synchronization process is as for the PSTN 
interworking case (see subclause 9.2.3.4). In case of interworking to the ISDN unrestricted digital bearer service the 
following synchronization process shall be performed: 

10.2.4.10.1 V.1 10 and V.120 Frame synchronizations 

The ISDN frame synchronizations will need to be mapped to the frame synchronizations utilized on the MSC/IWF to 
MSC link. 

10.2.4.10.2 RLP Frame start indication 

The frame start indication is defined in 3GPP TS 48.020. Link establishment and frame error recovery are defined in 
3GPP TS 24.022. 

10.2.4.10.3 L2R Frame synchronizations 

The synchronizations of user data and its interaction between the L2R function and RLP function are defined in 3GPP 
TS 27 series. 

10.2.4.10.4 Establishment of end-to-end terminal synchronizations 

Prior to exposing the traffic channel of a PLMN connection to transmission of user data, the controlling entities of the 
connection shall assure of the availability of the traffic channel. This is done by a so called synchronization process: 

starting on the indication of "physical connection established" resulting from the PLMN -inherent outband 
signalling procedure This indication is : 

- for MOC: on sending the CONNECT message; 

- for MTC: on sending the CONNECT ACKNOWLEDGE message; 

for mobile initiated in-call modification: on sending the MODIFY COMPLETE message (which is sent after 
reception of the ASSIGNMENT COMPLETE or RAB ASSIGNMENT RESPONSE message); and 

- for network initiated in-call modification: on reception of the ASSIGNMENT COMPLETE or RAB 
ASSIGNMENT RESPONSE message; 

ending by indicating the successful execution of this process to the controlling entity, which then takes care of 
the further use of the in-band information (data, status). 

Network interworking within an MSC/IWF is concerned with the terminating side (to the UE) and the transit side 
(to the fixed network) of a connection. Both sides shall be treated individually related to the synchronization process. 

10.2.4.10.4.1 Terminating side (towards tine UE) 
The procedures are the same as for the modem case. 

1 0.2.4.1 0.4.2 Transit side (towards the fixed network) 

Depending upon implementation, the synchronization of the V. 1 10 or V. 120 rate adaptation protocol on the ISDN 
transit network may be performed either after RLP establishment or in parallel to the RLP establishment. In case of the 
parallel establishment, data received from the transit side during RLP establishment shall be stored within the L2R 
buffers until the RLP establishment at the terminating side has been finished. When the RLP has been established and 
on recognizing frame alignment the information from/to the RLP is mapped by the L2R entity applicable to this 
particular bearer capability. 
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For V. 1 10 rate adaptation on the ISDN, the synchronization process consists of sending the V. 1 10 frame structure and 
looking for incoming frame synchronization according to the procedures in ITU-T Recommendation V.l 10. 

For V.120 rate adaptation the following applies. In Multiple frame acknowledged mode, data (I frames) may be sent 
following an exchange of SABME and UA in the traffic channel. In Unacknowledged mode, data (UI frames) may be 
sent immediately after an ISUP CONNECT or CONNECT COMPLETE message has been received on the ISDN 
signalling channel. Optionally, an XID exchange may take place in the traffic channel to verify link integrity. 

Note. V.120 allows UI frames to be sent in Multiple frame acknowledged mode at any time in addition to I frames. 
Whilst the IWF shall not follow this procedure when sending frames, such a sequence of I and UI frames may be 
received by the IWF. Although not specified in V.120, it is recommended that the IWF should deliver to the UE, the 
contents of the sequence of I and UI frames in the order in which they are received. 

For PIAFS rate adaptation the following applies. Data frame is sent following an exchange of initial negotiation and 
control frame in the traffic channel. 

1 0.2.4.1 1 Data compression 

When data compression is invoked within a non-transparent bearer service, interworking to the ISDN is realized by 
mapping the PLMN user rate to at least the same user rate in the ISDN. When the ISDN user rate is the same flow 
control will ensure data integrity, but the overall performance will be slow. When the ISDN user rate is higher the 
overall performance may be faster. 

1 0.2.4.1 2 Additional aspects of V.l 20 Interworking 

v.120 rate adaptation may be invoked with asynchronous services only. V.120 is applicable to both UDI and RDI 
connections. 

10.2.4.12.1 V.120 Signalling parameters 

The signalling parameters relevant to V.120 will be carried in the ISDN LLC and PLMN BC and PLMN LLC 
information elements. The mapping of the parameter values takes place in the MSC/IWF. 

For mobile terminated calls both single-numbering and multi-numbering scenarios may apply, as defined in 
subclause 9.2.2. The HLR shall not store an ISDN LLC with the MSISDN. 

10.2.4.12.2 v.120 Protocol parameters 

The following restrictions apply for the parameters relevant for V. 120: 

BS 20 NT will use the protocol sensitive asynchronous mode. As a consequence, the rate adaption header shall 
always be present. 

Only the default logical link will be established, i.e. the LLI negotiation value is "Default, LLI=256 only". 

V.120 recommends the use of the multiple frame acknowledged information transfer procedure for the protocol 
sensitive mode of operation. 

The IWF shall use the default value for the V.120 window size and the default value for the maximum transmit 
information field size. It shall be able to receive frames with the default maximum size. 

NOTE: V.120 does not specify the values for these and other HDLC -related parameters directly. They are 

specified in Q.922 (1992) section 5.9. The information field includes the V.120 terminal adaption data 
field, the rate adaption header and the header extension (Control State octet), if present. 

10.2.4.12.3 Data compression on the ISDN 

Whilst V. 1 10 rate adaptation does not support standardized data compression, V.42bis data compression may be used 
with V.120 protocol sensitive asynchronous mode. This is described in V.120 (10/96) annex C. 
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10.2.4.12.4 



Use of the V.I 20 Control State (header extension) octet 



The bits in the V.120 Control State octet are not used for the control of V.24 interface circuits. In unacknowledged 
mode the RR bit in the Control State octet is used to carry flow control information between the peer terminal adaption 
protocol entities. In acknowledged mode the Control State octet is not required. 

1 0.2.4.1 3 Interworking with restricted 64 kbit/s networks 
10.2.4.13.1 Rate adaptation 

Both V. 110 and V. 120 rate adaption protocols may be used on a restricted 64 kbit/s network. 

For V.l 10 rate adaption, the procedure is described in ITU-T Recommendation 1.464. The RA2 function shall set the 
8th bit of each octet in the 64 kbit/s stream to binary 1 . A consequence of this is that the highest permitted intermediate 
rate is 32 kbit/s. At the receiver, the 8th bit shall be ignored. 

Rec. V.120 states that the user data shall be rate adapted to 56 kbit/s by using only the first 7 bits of each octet in the 
64 kbit/s stream. The 8th bit shall be set to binary 1 . At the receiver, the 8th bit shall be ignored. 



10.2.4.13.2 



MSC - ISDN signalling 



When interworking indirectly with restricted 64 kbit/s networks the ISDN BC information element shall be coded 
according to ETR 018 (as shown in the notes to tables 7A and 7B). The information corresponding to the PLMN BC-IE 
shall be communicated in the ISDN LLC -IE which shall be provided by the UE for mobile originated calls. 

In the case of direct interworking, an ITC = RDI in the PLMN BC-IE maps on to an ITC = RDI in the ISDN BC-IE for 
both MO and MT calls. 

10.2.4.14 Service level up and down grading 

Text in 9.2.4.12 applies here as well. 

10.2.4.15 Interworking in Frame Tunneling Mode 

Figure 14 below shows the protocol stack used for FTM. The interface between the two asynchronous-synchronous 
conversion functions in the IWF and the remote terminal adapter (TA) is a 64 kbit/s UDI or a 56 kbit/s RDI connection. 
X.31 flag stuffing is used to adapt the rate between the two conversion functions. Data transparency is provided through 
bit stuffing. 



Higher layer 
(e.g., PPP) 



^ 



^ 



TAF 



L2RC0P 



RLP 



LI 



MSC/IWF 




Conv 
A-HDLcTs-HDLC 



Higher layer 
(e.g., PPP) 



S-HDLC 



A-HDLC 



Figure 14: The FTM protocol stack 

Data compression between the TAF and the IWF is optionally applied. The asynchronous to synchronous HDLC 
conversion follows from ISO/IEC 3309[48]. 
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A particular aspect of the asynchronous HDLC protocol is the provision of control character transparency. This means 
that flags (0x7E) and the control escape character (0x7D) are escaped, by insertion of the control escape character in 
front of the character to be escaped, and that the 6"^ bit of the escaped character is complemented (i.e., the escaped 
character is XOR'ed with 0x20). ISO/IEC 3309[48] allows additional control characters to be escaped by prior 
agreement or negotiation between the peer entities. For instance, in PPP [49], a negotiation procedure is defined using 
an Asynchronous Control Character Map (ACCM). By examining the contents of the HDLC frames that pass through it, 
the IWF shall identify whether the higher layer protocol is PPP, in which case, it shall detect and interpret the ACCM 
negotiation result. If PPP is used, the conversion function in the IWF shall apply a default ACCM until another is 
negotiated. 

1 0.2.4.1 6 Additional aspects of PIAFS Interworking 

PIAFS has several U-Plane protocol suites, but "Data Transmission Protocol (fixed rate)" [50] is only applied for 
UTRAN lu mode in consideration of simplicity. Details of frame structure and retransmission procedure etc. conform to 
reference [50]. 

In case of 32kbit/s mode, IWF performs rate adaptation based on 1.460 for fixed network. 

In case of 64 kbit/s mode, restriction on throughput may be caused by (the maximum frame length of 572bits in RLP). 

1 0.2.5 DTE/DCE interface (Filtering) 

This is described in section 9.2.5. 

1 0.3 Interworking Alternate speech facsimile group 3 calls 
1 0.3.1 Alternate speech data bearer interworking 
10.3.1.1 General 

The procedure for the alternate speech/facsimile group 3 service is invoked at the UE-MSC link during the call set-up 
phase. This service is invoked by indication of repeated bearer capability information elements in the setup message 
and/or call confirmed message, respectively (preceded by a repeat indicator "circular"), one indicating speech and the 
other indicating "facsimile group 3" plus user rate etc., as for normal single calls. The bearer capability first indicated 
i.e. speech or facsimile determines the first selection required of the network by the subscriber. Depending on the type 
of service requested and direction of call establishment (MO/MT, see relevant clauses of the 3GPP TS 27 series) low 
layer and high layer capabilities may also be included. The MSC/IWF will perform both compatibility checking and 
subscription checking for mobile originated calls and optionally for mobile terminated calls (single numbering scheme) 
on both sets of capabilities as for normal data calls. If either the subscription check or the compatibility check fails then 
the call shall be rejected. The only exception to this is when TS61/TS62 negotiation takes place, see 3GPP TS 27.001. 

As regards the supplementary services the application rules are laid down in 3GPP TS 22.004. 

The speech phase of the call, when invoked, is handled by the transcoder and will utilize the normal telephony 
teleservice interworking requirements and mobile network capabilities. The Facsimile group 3 phase of the call, when 
invoked, shall utilize the appropriate data interworking capability (e.g. IWF) and shall use the transparent mobile 
network capability in A/Gb mode or the non-transparent mobile network capability in UTRAN lu mode. 

The network shall provide, for service and operational reasons, a rapid and reliable changeover of capability upon 
request from the mobile user. This changeover may involve the disabling, by-passing or introduction of particular 
network functions (e.g. speech coder, modem etc.) and change of the channel configuration on the radio interface. This 
changeover is initiated on the receipt of the "MODIFY" message (see 3GPP TS 24.008) from the UE. The network 
itself will not initiate a changeover. 
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1 0.3.1 .2 Mobile originated ISDN terminated 

If one bearer capability information element indicates the ITC value "facsimile group 3", the call set up is as for the 
PSTN case. Interworking is provided to the ISDN bearer service 3,1 kHz audio for the whole connection, including the 
speech phase. The MODIFY message (see 3GPP TS 24.008) will be generated by the mobile subscriber. This message 
is not transmitted to the ISDN, i.e. no outband correlation between the user on the fixed network and the mobile user 
will be possible. In this instance it is necessary for change of network capabilities to be carried out in the mobile 
network. 

1 0.3.1 .3 ISDN originated mobile terminated 

In principle this is handled as for a normal ISDN originated call. 

However when the calling user indicates an ISDN BC-IE with an ITC value "3,1 kHz audio" and an HLC "facsimile 
group 3", i.e. the call arrives at the PLMN with compatibility information allowing for deducing the Teleservice 
"Facsimile transmission", the call setup is as described in subclause 10.2.2.3 case 3 in the HLR, and subclause 10.2.2.4 
case 5 in the VMSC. 

In the information transfer phase the call is dealt with as indicated in the previous paragraph. 

1 0.4 3G-H.324/M calls over UDI/RDI 

3G-H.324/M calls provide UDI/RDI (e.g. 32 kbit/s transparent data, 56 kbit/s transparent data or 64 kbit/s transparent 
data). H.223 and H.245 flow is not terminated in the MSC. 

3G-H.324 calls over 64 kbit/s transparent data and 56kbit/s transparent data can be connected to H. 324/1 calls over 
UDI/RDI. H.223 protocol is transparent to IWF. 

In case of 3G-H.324M calls over 32 kbit/s, IWF which performs rate adaptation between 64kbit/s and 32kbit/s is used. 
Rate adaptation is based on ITU-T Recommendation 1.460. 

The Service Change and Fallback functionality for UDI/RDI multimedia calls is described in 3GPP TS 23.172 [83]. 

The support of IWF which transcodes the multiplexes and the content of control, audio, video and data in MSC is FFS. 

1 0.4.1 Mobile originated multimedia call 
10.4.1.1 Call setup 

The setup message sent by the UE contains either a multimedia BC-IE indicating a multimedia only call request (i.e. no 
fallback / service change allowed) or both a speech BC-IE and a multimedia BC-IE to indicate the support of fallback 
and service change (see 3GPP TS 27.001 [43] and 3GPP TS 24.008 [40]). 

The MSC shall not accept a requested service to which the user is not provisioned for. Provided that the user is 
provisioned for the BS30 bearer service - and/or speech the following applies : 

in case of a multimedia only BC-IE, the MSC shall either accept the setup as such or with modifications sent to 
the UE in the call proceeding message (see 3GPP TS 27.001 [43]) ; 

in case of both a speech BC-IE and a multimedia BC-IE in either order, the MSC shall either accept the 
possibility of fallback or service change by responding with the two BC-IEs in the same order as received, in the 
reverse order (relayed from terminating user), or turn the call to a speech call by sending only a speech BC-IE in 
the call proceeding message, or turn the call to a multimedia only call by sending only the multimedia BC-IE in 
the call proceeding message (see 3GPP TS 27.001 [43]). 

in case of a multimedia BC-IE with FNUR = 32 kbit/s and a speech BC-IE, the MSC shall reply with only a 
multimedia BC-IE in the call proceeding message (see 3GPP TS 23.172 [83]). 
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1 0.4.1 .2 Fallback after setup 

If the MSC has accepted the possibiHty of a fallback and service change, and the transit network or the terminating side 
does not allow one of the bearers, the MSC shall initiate an In-Call Modification procedure (see 3GPP TS 24.008 [40]) 
in order to fallback to the allowed mode. As a result of the procedure, the radio and network resources are modified and 
the relevant channel is set up between the calling UE and the fixed network. If the fallback fails, e.g. due to an 
unsuccessful In-Call Modification procedure, the MSC shall clear the call. 

1 0.4.1 .3 User initiated service change after setup 

If the MSC has accepted the possibility of a service change and the user initiates an In-Call Modification procedure (see 
3GPP TS 24.008 [40]) in order to change the service either from speech to multimedia or vice-versa, the MSC shall 
invoke the service change as an In-Call Modification procedure. As a result of the procedure, the radio and core 
network resources are modified in order to comply with the requested service change. 

1 0.4.2 Mobile terminated multimedia call 

10.4.2.1 Call setup 

If the user is provisioned to use both the transparent bearer service (for multimedia) and the speech teleservice, and if 
the network supports both services and the service change functionality, the MSC shall send both a multimedia BC-IE 
and a speech BC-IE in the setup message to the mobile station. In case the MSC receives a multimedia call, the 
multimedia BC-IE is prioritised (first BC). In case the MSC receives a speech call, the speech BC is prioritised. 

If the user is provisioned to use only the transparent bearer service and if the network supports the multimedia service, 
the MSC shall only send a multimedia BC-IE, which results in a fallback to multimedia if the call was a speech call. 

If the user is provisioned to use only the speech teleservice, the MSC shall only send a speech BC-IE, which results in a 
fallback to speech if the call was a multimedia call. 

In case both a speech BC-IE and a multimedia BC-IE are included in the setup message, the mobile station shall either 
accept the service change capability by responding with two BC-IEs in the same or reversed order, or turn the call to a 
speech call by sending only a speech BC-IE in the call confirmed message, or to a multimedia only call (i.e. no service 
change allowed) by sending only a multimedia BC-IE in the call confirmed message. 

In case of a multimedia only BC-IE in the setup, the UE may accept the setup as such or with modifications sent to the 
MSC in the call confirmed message. 

1 0.4.2.2 User initiated service change after setup 

If the MSC supports the possibility of a service change and the user initiates an In-Call Modification procedure (see 
3GPP TS 24.008 [40]) in order to change the service either from speech to multimedia or vice-versa, the MSC shall 
invoke the service change as an In-Call Modification procedure. As a result of the procedure, the radio and core 
network resources are modified in order to comply with the requested service change. 



1 1 Interworking between A/Gb mode MSC and lu mode 
MSC 

11.0 Signalling issues 

11 .0.1 Loss of BC Information during Handover from A/Gb mode to UTRAN 
lu mode 

In the case of inter-MSC handover from A/Gb mode to UTRAN lu mode, the serving A/Gb mode MSC/VLR sends a MAP 
message Prepare Handover carrying the BSSMAP message Handover Request. This message includes the parameter Channel 
Type, indicating whether radio resources are to be allocated for speech or data (parameter 'Speech or data indicator') and, among 
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other data, the type of data service (transparent/non transparent) and the user rates (both included in the parameter 'Data rate and 
transparency indicator'). 

As no other bearer capabiHty related parameters are received, it is not possible to distinguish between any other services than 
'speech', 'data transparent' and 'data non-transparent'. 

The mapping into QoS radio access parameters would be done as described in 3GPP TS 27.001[86], annex B, subclause B.1.13., 
limited to the services 'speech', 'data, non-transparent' and 'data, transparent'. 

1 1 .0.2 Handover from UTRAN lu mode to A/Gb mode 

In case a UTRAN lu mode call is set up in the CN, the EC IE parameters are mapped into QoS RAB parameters at call 
setup. 

If the CN has to perform a handover towards A/Gb mode, the non-anchor MSC needs to perform an assignment based 
on GSM traffic channel parameters. 

In case of handover from UTRAN lu mode to A/Gb mode, the anchor MSC maps the EC IE parameters into A/Gb 
mode traffic channel parameters. This requires that the EC IE is coded according to A/Gb mode protocol requirements, 
i.e. all those parameters ignored in UTRAN lu mode should nevertheless be correctly specified by the UE in order to 
perform a handover to A/Gb mode. 

1 1 .0.3 Loss of BC Information during Handover from A/Gb mode to 
GERAN lu mode 

Subclause 1 1.0.1 applies also to handover from A/Gb mode to GERAN lu mode. 

Additionally, the serving A/Gb mode MSC/VLR will include the parameter GERAN Classmark in the MAP message 
Prepare Handover, if this parameter is available. The GERAN Classmark, which indicates the capabilities of the ESS in 
the target cell (e.g. allowed channel codings and maximum number of traffic channels), shall be taken into account by 
the target MSC when it performs the mapping into QoS radio access parameters. 

1 1 .0.4 Handover from GERAN lu mode to A/Gb mode 

Subclause 11. 0.2 applies also to handover from GERAN lu mode to A/Gb mode. 

NOTE: The protocol requirements for the coding of the EC IE according to GERAN lu mode are the same as for 
A/Gb mode, i.e. all those parameters needed in order to perform a handover to A/Gb mode are available. 

1 1 .0.5 Handover from UTRAN lu mode to GERAN lu mode 

The serving UTRAN lu mode MSC/VLR will send a MAP message Prepare Handover carrying the RANAP message 
Relocation Request. When setting the QoS RAE parameters in the RANAP message Relocation Request, the serving 
UTRAN lu mode MSC/VLR shall take into account: 

the GERAN Classmark of the target cell, if this parameter is available; 

the allowed channel codings and the maximum number of traffic channels from the EC IE, if the serving MSC is 
the anchor MSC; and 

the allowed radio interface rates (included in the parameter Channel Type), if the serving MSC is not the anchor 
MSC. 

This requires that the EC IE is coded according to GERAN lu mode protocol requirements, i.e. all those parameters 
ignored in UTRAN lu mode should nevertheless be correctly specified by the UE in order to perform a handover to 
GERAN lu mode. Furthermore, it requires that the anchor MSC maps the EC IE parameters into A/Gb mode traffic 
channel parameters and includes the parameter Channel Type in the MAP message Prepare Handover also for basic 
handover to UTRAN lu mode. 
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1 1 .0.6 Handover from GERAN lu mode to UTRAN lu mode 

The serving GERAN lu mode MSC/VLR will send a MAP message Prepare Handover carrying the RANAP message 
Relocation Request. When setting the QoS RAB parameters in the RANAP message Relocation Request, the serving 
GERAN lu mode MSC/VLR shall take the mode of the tai-get cell into account. (See 3GPP TS 27.001 [86], annex B, 
subclause B.1.13. For non-transparent services, some of the RAB Sub flow Combination bit rates are supported in 
GERAN lu mode, but not in UTRAN lu mode.) 

11.1 Handover to A/Gb mode MSC 

After a handover from an lu mode MSC or an A/Gb mode MSC to an A/Gb mode MSC the user plane between the 
anchor MSC and the visited MSC shall comply to: 

- the standard A-interface protocols if both MSCs are connected via a TDM interface, i.e.: 

- A-TRAU or modified V. 1 10 frames as defined in 3GPP TS 44.021 [27] and 3GPP TS 48.020 [28]; 

up to four 16kbit/s substreams are multiplexed in one 64kbit/s channel (Split/Combine function and 
Multiplexing function as defined in 3GPP TS 44.021 [27] and 3GPP TS 48.020 [28]). 

- the Nb UP protocol if the anchor MSC or MGW and the visited MSC or MGW are connected via an ATM 
transport interface or IP transport interface in a BICC based CS CN. The NbUP shall be configured in support 
mode, the data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 
ms, in accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. PDU type is used, i.e., payload CRC 
is applied. This is needed for the framing to be handled the same for all transports but the Frame Quality 
Classification control shall be ignored (3GUP property Delivery Of Erroneous SDUs = yes) and therefore 
interim nodes shall only pass on the CRC. The data is encoded between MSC-B/MGW-B (non- Anchor) and 
MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause 11 a. 1.3 is applicable. 

- the CLEARMODE payload type, see IETF RFC 4040 [92], within RTP/IP if SIP-I over Nc is deployed in the 
CN. The data is transported in a 64 kbit/s bit stream. The data is encoded between MSC-B/MGW-B (non- 
Anchor) and MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause 1 la. 1.3 is appUcable. 

Editor's Note: The packetisation time for the CLEARMODE payload type is FFS. 

1 1 .2 Handover from A/Gb mode MSC to UTRAN lu mode MSC 

After a handover from an A/Gb mode MSC to an UTRAN lu mode MSC the user plane between the anchor MSC and 
the visited MSC shall comply to: 

- the A-TRAU' protocol if both MSCs are connected via a TDM interface except for FNUR = 32 kbit/s (ITC = 
UDI), FNUR = 56 kbit/s (ITC=RDI) and FNUR = 64 kbit/s (ITC=UDI). For these exceptions a plain 64 kbit/s 
channel is used between the MSCs. 

- the Nb UP protocol if the anchor MSC or MGW and the visited MSC or MGW are connected via an ATM 
transport interface or IP transport interface ina BICC based CS CN. The NbUP shall be configured in support 
mode, the data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 
ms, in accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. PDU type is used, i.e., payload CRC 
is applied. This is needed for the framing to be handled the same for all transports but the Frame Quality 
Classification control shall be ignored (3GUP property Delivery Of Erroneous SDUs = yes) and therefore 
interim nodes shall only pass on the CRC. The data is encoded between MSC-B/MGW-B (non- Anchor) and 
MSC-A/MGW-A (Anchor) as for the TDM case (A-TRAU" protocol or plain 64kbits/s). Furthermore, Clause 
11a. 1.3 is applicable. 

- the CLEARMODE payload type, see IETF RFC 4040 [92], within RTP/IP if SIP-I over Nc is deployed in the 
CN. The data is transported in a 64 kbit/s bit stream. The data is encoded between MSC-B/MGW-B (non- 
Anchor) and MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause 11a. 1.3 is applicable. 

Editor's Note: The packetisation time for the CLEARMODE payload type is FFS. 
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1 1 .3 Handover from A/Gb mode MSC to GERAN lu mode MSC 

11.3.1 User plane for transparent services 

After a handover from a GERAN A/Gb mode MSC to a GERAN lu mode MSC the user plane for transparent services 
between the anchor MSC and the visited MSC shall comply to: 

- the A-TRAU" protocol except for FNUR = 32 kbit/s (ITC = UDI), FNUR = 56 kbit/s (ITC=RDI) and FNUR = 
64 kbit/s (ITC = UDI). For these exceptions a plain 64 kbit/s channel is used between the MSCs. The rate 
adaptation between 64 kbit/s and 32 kbit/s is based on ITU-T Recommendation 1.460. 

- the Nb UP protocol if the anchor MSC or MGW and the visited MSC or MGW are connected via an ATM 
transport interface or IP transport interface in a BlCC based CS CN. The NbUP shall be configured in support 
mode, the data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 
ms, in accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. PDU type is used, i.e., payload CRC 
is applied. This is needed for the framing to be handled the same for all transports but the Frame Quality 
Classification control shall be ignored (3GUP property Delivery Of Erroneous SDUs = yes) and therefore 
interim nodes shall only pass on the CRC. The data is encoded between MSC-B/MGW-B (non- Anchor) and 
MSC-A/MGW-A (Anchor) as for the TDM case (A-TRAU" protocol or plain 64kbits/s). Furthermore, Clause 
11a. 1.3 is applicable. 

- the CLEARMODE payload type, see IETF RFC 4040 [92], within RTP/IP if SlP-1 over Nc is deployed in the 
CN. The data is transported in a 64 kbit/s bit stream. The data is encoded between MSC-B/MGW-B (non- 
Anchor) and MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause Ua. 1.3 is applicable. 

Editor's Note: The packetisation time for the CLEARMODE payload type is FFS. 

1 1 .3.2 User plane for non-transparent services 

After a handover from a GERAN A/Gb mode MSC to a GERAN lu mode MSC the user plane for transparent services 
between the anchor MSC and the visited MSC shall comply to: 

- the A-TRAU"" protocol as defined below for the RAB subflows with 12 kbit/s, 24 kbit/s, 36 kbit/s and 48 kbit/s 
and the A-TRAU" protocol for the RAB subflows with 14,4 kbit/s, 28,8 kbit/s, 43,2 kbit/s and 57,6 kbit/s, if 
both MSCs are connected via a TDM interface. 

- the Nb UP protocol if the anchor MSC or MGW and the visited MSC or MGW are connected via an ATM 
transport interface or IP transport interface in a BlCC based CS CN. The NbUP shall be configured in support 
mode, the data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 
ms, in accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. PDU type is used, i.e., payload CRC 
is applied. This is needed for the framing to be handled the same for all transports but the Frame Quality 
Classification control shall be ignored (3GUP property Delivery Of Erroneous SDUs = yes) and therefore 
interim nodes shall only pass on the CRC. The data is encoded between MSC-B/MGW-B (non- Anchor) and 
MSC-A/MGW-A (Anchor) as for the TDM case (A-TRAU"" or A-TRAU" protocol). Furthermore, Clause 

11a. 1.3 is applicable. 

- the CLEARMODE payload type, see IETF RFC 4040 [92], within RTP/IP if SlP-1 over Nc is deployed in the 
CN. The data is transported in a 64 kbit/s bit stream. The data is encoded between MSC-B/MGW-B (non- 
Anchor) and MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause 1 la. 1.3 is applicable 

Editor's Note: The packetisation time for the CLEARMODE payload type is FFS. 

1 1 .4 Handover within lu mode PLMNs 

After a handover from an lu mode MSC to a UTRAN lu mode MSC the user plane between the anchor MSC or MGW 
and the visited MSC or MGW shall comply to: 

the A-TRAU' protocol if both MSCs are connected via a TDM interface except for the transparent case FNUR = 
32 kbit/s (ITC = UDI or RDl), FNUR = 56 kbit/s (1TC=RD1) and FNUR = 64 kbit/s (1TC=UD1). For these 
exceptions a plain 64 kbit/s channel is used between the MSCs. The rate adaptation between 64 kbit/s and 
32 kbit/s is based on ITU-T Recommendation 1.460 [2]. 
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- the Nb UP protocol if the anchor MSC or MGW and the visited MSC or MGW are connected via an ATM 
transport interface or IP transport interface in a BICC based CS CN. The NbUP shall be configured in support 
mode, the data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 
ms, in accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. PDU type is used, i.e., payload CRC 
is applied. This is needed for the framing to be handled the same for all transports but the Frame Quality 
Classification control shall be ignored (3GUP property Delivery Of Erroneous SDUs = yes) and therefore 
interim nodes shall only pass on the CRC. The data is encoded between MSC-B/MGW-B (non- Anchor) and 
MSC-A/MGW-A (Anchor) as for the TDM case (A-TRAU" protocol or plain 64kbits/s). 

- the CLEARMODE payload type, see IETF RFC 4040 [92], within RTP/IP if SIP-I over Nc is deployed in the 
CN. The data is transported in a 64 kbit/s bit stream. The data is encoded between MSC-B/MGW-B (non- 
Anchor) and MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause 11a. 1.3 is appUcable. 

Editor's Note: The packetisation time for the CLEARMODE payload type is FFS. 

After a handover from an lu mode MSC to a GERAN lu mode MSC the user plane between the anchor MSC or MGW 
and the visited MSC or MGW shall comply to 

the A-TRAU" or A-TRAU' protocol or a plain 64 kbit/s channel if both MSC are connected via a TDM interface. 
The A-TRAU" protocol shall be used for transparent services except for the transparent cases FNUR = 32 kbit/s 
(ITC = UDI), FNUR = 56 kbit/s (ITC=RDI) and FNUR = 64 kbit/s (ITC=UDI). For these exceptions a plain 64 
kbit/s channel is used between the MSCs. The rate adaptation between 64kbit/s and 32kbit/s is based on ITU-T 
Recommendation 1.460. For non-transparent services, the A-TRAU"" protocol shall be used for the RAB 
sub flows with 12 kbit/s, 24 kbit/s, 36 kbit/s and 48 kbit/s and the A-TRAU" protocol shall be used for the RAB 
subflows with 14,4 kbit/s, 28,8 kbit/s, 43,2 kbit/s and 57,6 kbit/s. 

- the Nb UP protocol if the anchor MSC or MGW and the visited MSC or MGW are connected via an ATM 
transport interface or IP transport interface in a BICC based CS CN. The NbUP shall be configured in support 
mode, the data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 
ms, in accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. PDU type is used, i.e., payload CRC 
is applied. This is needed for the framing to be handled the same for all transports but the Frame Quality 
Classification control shall be ignored (3GUP property Delivery Of Erroneous SDUs = yes) and therefore 
interim nodes shall only pass on the CRC. The data is encoded between MSC-B/MGW-B (non- Anchor) and 
MSC-A/MGW-A (Anchor) as for the TDM case (A-TRAU"" protocol, A-TRAU" protocol or plain 64kbits/s). 
Furthermore, Clause 11a. 1.3 is applicable. 

- the CLEARMODE payload type, see IETF RFC 4040 [92], within RTP/IP if SIP-I over Nc is deployed in the 
CN. The data is transported in a 64 kbit/s bit stream. The data is encoded between MSC-B/MGW-B (non- 
Anchor) and MSC-A/MGW-A (Anchor) as for the TDM case. Furthermore, Clause 1 la.1.3 is apphcable 

Editor's Note: The packetisation time for the CLEARMODE payload type is FFS. 

1 1 .5 Handover for 56kbit/s 

The FNUR = 56 kbit/s in transparent mode can be supported in A/Gb mode by two configurations: 

1 . without IWF with the following channel codings 

- 2*TCH/F32.0 

- 5*TCH/F9.6 

2. with IWF with the following channel coding 

- 4*TCH/F14.4 
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The FNUR = 56 kbit/s in transparent mode is supported in lu mode by a configuration without IWF only. Therefore 
handover for 56kbit/s in transparent mode between lu mode MSC and A/Gb mode can be supported only for 
configurations without IWF. 

Note: Handover between configurations with and without IWF are also not supported within A/Gb mode. 

1 1 .6 Void 



1 1 a Transport Protocols 

11 a. 1 Core Network 
11 a. 1.0 Overview 

The Nb UP protocol is used to transport user data in BICC based Core Network, see 3GPP TS 29.415 [80]. 

The RTP protocol is used to transport user data in SIP -I based Core Network, see 3GPP TS 29.414 [93]. The 
CLEARMODE payload type shall be appUed, see IETF RFC 4040 [92] for 64k data. 

Figures 16 and 16a below show the different cases to consider: 

1 . Transport on the access side of the IWF 

2. Transport beyond the IWF, i.e., between the IWF and the fixed network 
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Figure 16: Transport of data within thie BICC based Core Network 
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Figure 16a: Transport of data within the SIP-I based Core Network 
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11a.1.1 Void 



11 a. 1 .2 Transport beyond the I WF 



11a.1.2.1 



UDI and RDI 



The data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 ms, in 
accordance with Annex P of ITU-T Recommendation 1.366.2 [81]. For BICC based CS CN, PDU type is used, i.e., 
payload CRC is appUed. 

At the border between the CN and the fixed (ISDN) network, for BICC based CS CN conversion between Nb UP and 
TDM shall be applied. For SIP-I based CS CN conversion between "CLEARMODE" payload type and TDM shall be 
applied. In case of RDI interworking, the 56 kbit/s RDI bit stream is transmitted within the CN as 64 kbit/s bit stream 
where the last bit of each octet is ignored. For this reason the octet alignment shall be preserved in the SDUs transported 
in the CN. 



11a.1.2.2 



Modem 



The modem signals are PCM encoded and transported on a 64 kbit/s bit stream. The transmission is otherwise identical 
to the UDI/RDI case, see Section 11 a. 1.2.1 

1 1 a.1 .3 Transport on the access side of the IWF 
11a.1.3.0 Inter MSC-Relocation 

After inter-MSC relocation. Clause 1 1 is applicable. 

Furthermore,for the BICC based CS CN the Nb UP is used in support mode, for SIP-I CLEARMODE/RTP shall be 
used; all interim Server nodes are assumed not to be aware of the relocation case - i.e. receive BICC lAM with same 
information as for connections beyond the IWF (Clause 1 1 a. 1 .2). 

Figure 17 indicates the relevant connections, where MSC-A/MGW-A are the Anchor nodes and MSC-B/MGW-B are 
the Non-Anchor nodes. The CSD MGW Termination Properties for the terminations in Figure 17 shall be used as 
described in Tables 16 and 17. 
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Figure 17: Bearer Independent connections for Inter-MSC SRNS Relocation 

The lu UP for BICC based CS CN shall be initialised on each Nb leg in a forward direction (regardless if Forward 
Bearer or Backward Bearer procedures are used), i.e. in the direction of the lAM. For further details see TS 23.205 [83]. 

When setting up the call leg towards MSC-B, the anchor node MSC-A shall request an UDI bearer in out-of-band 
signalling. For UDI/RDI multimedia calls with fallback and service change according to 3GPP TS 23.172 [17], the 
anchor node MSC-A shall negotiate the multimedia dummy codec as specified in 3GPP TS 23.153 [91] . 
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Editor's Note: SCUDIF for SIP-I on Nc is FFS. 

Figure 1 8 shows the scenario where the IWF resides in a MGW directly interfacing an lu or A interface, as encountered 
e.g. before an inter-MSC handover. The CSD MGW Termination Properties for the terminations in Figure 18 shall be 
used as described in Tables 16 and 17. 
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Figure 18: IWF in MGW interfacing lu or A interface 

1 1 a.1 .3.0a Several MGWs controlled by same MSC server 

In other cases than inter-MSC relocation where the IWF is not interfacing an lu UP layer protocol entity, the following 
bullets are applicable (For example, an MSC-server may control two MGWs and route the call through both, as one 
MGW interfaces lu and the other one hosts the user plane part of the IWF): 

If the access network uses A/Gb mode, the same transport as described in Clause 11.1 shall be applied. 

If the access network uses lu mode, the same transport as described in Clause 1 1 .4 shall be applied. 

Furthermore, for BICC CS CN the Nb UP is used in support mode. 

Figure 19 indicates the relevant connections, where MGW-A is where the IWF resides. The CSD MGW Termination 
Properties for the terminations in Figure 19 shall be used as described in Tables 16 and 17. 
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Figure 19: Transport on the access side of the IWF if the same MSC server controls one MGW A 
hosting the IWF and another MGW B interfacing the radio access network 

The MSC server selects the direction of the luUP initialisation if BICC based CS CN. 
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11a.1.3.1 Non-Transparent CSD 



Table 16: Non-Transparent CSD MGW Termination Properties For Inter-IUISC SRNS Relocation 



Termination 


MSC-A 


MSC-B 


Intermediate 


Paclcages/Parameters 






Nodes 


TO 


T1 (lu) 


T1(A) 


T2 


T7 


T8 (lu) 


T8(A) 


T3, T4, T5, T6 


TMR 


TMR 


- 


- 


UDI 


UDI 


UDI 


UDI 


UDI 


threegcsd:plmnbc 
threegup:interface 


(NOTE 5) 






(NOTE 3) 




(NOTE 7) 


(NOTE 3) 




- 


PLMN BG 


PLMN BG 


PLMN BG 


- 


- 


- 


- 


GN 


RAN 


- 


GN 


GN 


RAN 


- 


GN 


threegup:initdir 


(NOTE 2) 






(NOTE 2) 


(NOTE 2) 






(NOTE 2) 


(NOTE 2) 


IN 


- 


OUT 


IN 


OUT 


- 


IN 




(NOTE 4) 






(NOTE 2) 


(NOTE 2) 






(NOTE 2) 


threegup:mode 








(NOTE 6) 


(NOTE 6) 








Support 


support 


- 


Support 


Support 


support 


- 


Support 


threegcsdeibitrate 
threegcsdigsmchancod 


(NOTE 2) 






(NOTE 2) 


(NOTE 2) 






(NOTE 2) 


- 


- 


- 


- 


- 


BITRATE 


- 


- 


- 


- 


GSMGG 


GSMGG 


- 


- 


- 


- 


IP Interface Type 








(N0TE1) 










NbolP(NOTE 


- 


AolP 


NbolP(NOTE 


NbolP(NOTE 


- 


AolP 


NbolP(NOTE S) 


Payload Type 


8) 




(NOTE 9) 


8) 


8) 




(NOTE 9) 




GLEARMODE 


- 


AolP 


GLEARMODE 


GLEARMODE 


- 


AolP 


GLEARMODE 




[92], G711 




(NOTE 10) 


[92] 


[92] 




(NOTE 10) 


[92] 




[1,x], orT.SS 

[y,z] 






(NOTE 11) 


(NOTE 11) 






(NOTE 11) 




(NOTE 11) 
















N0TE1 


GSM CC shall only be provided if TS is an A interface. GSM CO shall not be provided if TS is an lu interface. 




NOTE 2 


Only applicable for a BICC network. 






NOTES 


Optional 






NOTE 4 


Value depends on call direction: IN if terminating call, OUT if originating call. 






NOTES 


TMR is set according to the value received from ISDN/BIGG signalling. Im addition, a received USI may be supplied. If no TMR value from 1 


ISDN/BICC signalling is available, but the MSC determines with the help of PLIVIN 


_BGs exchanged with the UE that the call is a 


data call, it shall 


supply a value derived from the PLIVIN BC. 






NOTE 6 


If several MGWs are controlled by the same MSG server, the server may also select the other value. 




NOTE? 


For a data rate of 64 kbit/s, TMR 'UDI' may be supplied. For other data rates, TMR 'UDI' shall not be sent. 




NOTES 


The parameter may be supplied with value "NbolP" for a termination towards a SIP-I based GS GN. For termination towards a BIGG based GS 1 


CM, the parameter shall not be supplied. 






NOTE 9: For an A interface with TDIVI transport, the IP interface type shall not be supplied. 


For an A interface with IP transport, the value 


"AolP" may be 


supplied as IP interface type. 






NOTE 10: For an A interface with TDM transport, the Payload Type shall not be supplied. For an A interface with IP transport, CLEARMODE (see IETF RFC | 


4040 [92]) or Redundant RTP payload for Audio Data as specified in IETF RFC 2198 


[94] encapsulating the GLEARMODE payload shall be supplied as | 


payload type. 






NOTE 1 1 : The parameter shall be supplied for a termination towards a SIP-I based CS CN. 


For terminations towards a BIGG based GS GN, the parameter | 
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11a.1.3.2 Transparent CSD 



Table 17: Transparent CSD MGW Termination Properties For Inter-IUISC SRNS Relocation 



Termination 


MSC-A 




MSC-B 




Intermediate 


Paclcages/Parameters 










Nodes 


TO 


T1 (iu) 


T1(A) 


T2 


T7 


TS (iu) 


T8(A) 


T3, T4, T5, T6 


TMR 


TMR 


- 


- 


UDI 


UDI 


UDI 


UDI 


UDI 




(NOTE 6) 






(NOTE 4) 


(NOTE 10) 


(NOTE S) 


(NOTE 4) 




threegcsd:plmnbc 








(NOTE 10) 










- 


PLMN BC 


PLMN BC 


PLMN BC 


- 


- 


- 


- 


threegupiinterface 




(NOTE 9) 




(NOTE 10) 










CN 


RAN 


- 


CN 


CN 


RAN 


- 


CN 


threegup:mode 


(NOTE 3) 






(NOTE 3) 


(NOTE 3) 






(NOTE 3) 


(NOTE 3) 


transparent 


- 


Support 


Support 


transparent 


- 


Support 


threegup:initdir 


Support 






(NOTE 3) 


(NOTE 3) 






(NOTE 3) 


(NOTE 3) 


- 


- 


OUT 


IN 


- 


- 


IN 




(NOTE 5) 






(NOTE 3) 


(NOTE 3) 






(NOTE 3) 


threegcsden :bitrate 








(NOTE 7) 


(NOTE 7) 








- 


- 


- 


- 


- 


BITRATE 


- 


- 


threegcsd:gsmchancod 












(NOTE 1) 






- 


- 


GSMCC 


GSMCC 


- 


- 


- 


- 










(NOTE 2) 










IP Interface Type 


NbolP(NOTE 


- 


AolP(NOT 


NbolP(NOTE 


NbolP(NOTE 


- 


AolP 


NbolP(NOTE 




11) 




E 12) 


11) 


11) 




(NOTE 12) 


11) 


Payload Type 


CLEARMODE 


- 


AolP 


CLEARMODE 


CLEARMODE 


- 


AolP 


CLEARMODE 




[92] 




(NOTE 13) 


(NOTE 14) 


(NOTE 14) 




(NOTE 13) 


(NOTE 14) 




G.711 [1,x] 


















(NOTE 14) 
















N0TE1 


This is optional if rate is 64kb/s. In this case no rate adaptation is required. 










NOTE 2 


GSM CC shall only be provided if TS is an A interface. GSM CO shall not be provided if TS is an lu interface. 






NOTES 


Only applicable for a BICC network. 










NOTE 4 


Optional 










NOTES 


Value depends on call direction: IN if terminating call, OUT if originating call. 










NOTE 6 


TMR is set according to the value received from ISDN/BICC signalling. Im addition, a received USI may be suppliec 


. If no TMR value from 1 


ISDN/BICC signalling is available, but the MSC determines with the help of PLIVIN 


_BCs exchanged with the UE that the call is a data call, it shall | 


supply a value derived from the PLIVIN BC. 










NOTE? 


If several MGWs are controlled by the same MSC server, the server may also select the other value 








NOTES 


For a data rate of 64 kbit/s, TMR 'UDI' may be supplied. For other data rates, TMR 'UDI' shall not be sent. 






NOTE 9 


For a SCUDIF multimedia call, the MuMe codec shall be configured instead. 










NOTE 10: For a SCUDIF multimedia call, the IVIuMe codec shall be configured instead in case of BICC termination. 






NOTE 1 1 : The parameter may be supplied with value " NbolP" for a termination towards a SIP-I based CS CN 


For terminations towards a BICC based CS | 


CM, the parameter shall not be supplied. 








1 
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NOTE 12: For an A interface with TDIVI transport, the IP interface type shall not be supplied. For an A interface with IP transport, the value "AolP" may be 

supplied as IP interface type. 
NOTE 13: For an A interface with TDIVI transport, the Payload Type shall not be supplied. For an A interface with IP transport, CLEARMODE (see IETF RFC 

4040 [92]) or Redundant RTP payload for Audio Data as specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be supplied as 

payload type. 
NOTE 14: The payload type parameter shall be supplied for a termination towards a SIP-I based CS CM. For terminations towards a BICC based CS CN, the 
parameter shall not be supplied. 
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11a.2 NT services 

11 a. 2.1 lu interface and Nb interface at access side of IWF in a BICC based 
CSCN 

On the lu interface and if TDM or SIP -I is not used in the CN between the access network and the IWF, this paragraph 
is applicable, except for the Nb interface in the case of inter-MSC relocation. The lu and Nb user planes are used in 
support mode, see 3GPP TS 25.415 [42] and 3GPP TS 29.415 [80]. Each SDU corresponds to one RLP frame and, 
consequently, is 576 bits long. In GERAN lu mode another SDU size of 480 bits is possible. It carries two RLP frames 
of 240 bits and is used if TCH/F9.6 is used in GERAN. Each SDU is transported in one lu or Nb UP PDU of Type 1. In 
UTRAN lu mode, the range of RAB Subflow Combination bit rate values is 14,4 kbit/s, 28,8 kbit/s, 57,6 kbit/s, limited 
by the maximum bit rate, and varies with the transmission period on the Uu interface, which is 40 ms, 20 ms or 10 ms. 
In GERAN lu mode these values are valid if TCH/F14.4, TCH/28.8 or TCH/F43.2 is used. In addition GERAN lu mode 
has a RAB Subflow Combination bit rate of 43,2 kbit/s with a transmission period of 13/4 ms. If TCH/F9.6 is used, the 
range of RAB Subflow Combination bit rate values is 12 kbit/s, 24 kbit/s, 36 kbit/s, 48 kbit/s, limited by the maximum 
bit rate, and varies with the transmission period on the Um interface, which is 40 ms, 20 ms, 13/4 ms or 10 ms. A 
change in the transmission period is signalled to the IWF through the lu and Nb UP protocols. The lu or Nb UP 
primitive lu- or Nb-UP-DATA-REQUEST is invoked each time an RLP frame is ready to be sent from the IWF towards 
the UE. DTX indication is not used. 

The following table shows the connection between the RAB subflow combination bit rate and the AIUR. 

Table 18: Connection between the RAB subflow combination bit rate and AIUR for Non-Transparent 

CSD Services 



RAB subflow 
combination bit rate 


AIUR 


Used number of traffic channels and 
channel coding for GERAN lu mode 


Comment 


57,6 kbit/s 


57,6 kbit/s 


4XTGH/F14.4, 2xTGH/F28.8 


(Note 1) 


43,2 kbit/s 


43,2 kbit/s 


3XTGH/F14.4, 1xTGH/F43.2 


(Note 2) 


48 kbit/s 


38,4 kbit/s 


4XTCH/F9.6 


(Note 2) 


36 kbit/s 


28,8 kbit/s 


3XTCH/F9.6 


(Note 2) 


28,8 kbit/s 


28,8 kbit/s 


2XTGH/F14.4, 1xTGH/F28.8 


(Note 1) 


24 kbit/s 


19,2 kbit/s 


2XTCH/F9.6 


(Note 2) 


14,4 kbit/s 


14,4 kbit/s 


1XTGH/F14.4 


(Note 1) 


1 2 kbit/s 


9,6 kbit/s 


1XTGH/F9.6 


(Note 2) 


NOTE 1 : RAB subflow combination bit rate is used in UTRAN lu mode and GERAN lu mode 
NOTE 2: RAB subflow combination bit rate is only used in GERAN lu mode 



1 1 a.2.2 Nb interface at access side of IWF in a BICC based CS CN for 
Inter-MSC relocation 

For Inter-MSC relocation this paragraph is applicable for the Nb interface in BICC based CS CN between the access 
network and the IWF. The Nb UP protocol is applied in support mode and the SDU size is 320 bits, transmitted every 5 
ms. PDU type is used. The data within the PDU is encoded as A-TRAU" and A-TRAU" frames. 

1 1 a.2.3 Nb interface at network side of IWF in a BICC based CS CN 

If TDM is not used, then between the IWF and the fixed network (ISDN or PSTN), for the BICC based CS CN the Nb 
UP protocol is applied in support mode and the SDU size is 320 bits, transmitted every 5 ms. PDU type is used. 

1 1 a.2.4 Nb interface at access side of IWF in a SIP-I based CS CN 

The CLEARMODE RTP payload type shall be used with a framing period of 20 msecs. The data within the 
CLEARMODE RTP payload type shall be transported in a 64 kbit/s bit stream and shall be encoded as for the TDM 
case of the A interface. 
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1 1 a.2.5 Nb interface at network side of IWF in a SIP-I based CS CN 

For non-transparent CSD calls CLEARMODE [92] shall be supported in addition to G.711 [l,x] as RTF payload type. 
NOTE: G.71 1 will only be used if an offerer is not able to determine wether a call is a data call or a speech call. 
For facsimile calls T.38 [y,z] may be supported in addition to G.71 1. 

For SCUDIF (see TS 23.172 [83]), the "vnd.3gpp.clearmode" RTF payload type (see Annex C) shall be used. 
The negotiation of payload types is described in Clause 15. 

1 1 a. 2. 6 A interface witin IP transport 

The CLEARMODE RTF payload type (see IETF RFC 4040[92]) or Redundant RTF payload for Audio Data as 
specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be used. Transport without 
redundancy shall be supported. Transport with redundancy may be supported. Only the redundancy level 2 and level 3 
are applicable on the AoIF interface. 

Note: The redundancy level is signalled from the MSC server by the Mc interface as negotiated between the 
MSC server with the BSC. 

The data within the CLEARMODE RTF payload type shall be transported with a framing period of 20 ms in a 64 kbit/s 
bit stream and shall be encoded as for the TDM case of the A interface. 

11a.3 T services 
11 a. 3.0 lu interface 

On the lu interface, the lu UF is used in transparent mode, see 3GFF TS 25.415 [42]. The payload of the lu and Nb 
frames will consist of user data bits only for synchronous data, and RAO synchronous bit streams for asynchronous data. 

On the lu interfaces, the payload (SDU) size is fixed, determined by the bit rate. Following table shows SDU sizes. 
AAL2 is used. The AAL2 SSCS layer shall be supported for segmentation and re-assembly. 

Table 19: SDU sizes for Transparent CSD Services at lu interface 



Bit rate 


SDU Size (= RLC PDU payload size) 


28.8 kbit/s 


578 bits 


33.8 kbit/s 


672 bits 


32 kbit/s 


640 bits 


56/84 kbit/s 


640 bits 



The primitive lu-UF _UNIT-DATA-REQUEST is invoked at regular intervals in order to have a constant bit rate (every 
SDU). 

1 1 a.S.Oa Nb interface in BICC based CS CN 

If TDM is not used at the Nb interface, then the Nb UF protocol is applied in support mode and the SDU size is 
320 bits, transmitted every 5 ms. FDU type is used. 

1 1 a.3. 1 Avoidance of delay at RNC 

The TTI-to-CFS Facket packaging delay can be avoided by choosing the length of the CFS packet payload so that the 
payloads of an integer number of CFS Fackets fill one TTI. The contents of the whole TTI can be sent further towards 
the MSC immediately after the reception without waiting for the next TTI. 
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1 1 a. 3. 2 Recovery from the loss of ATM cells 

The ATM cell loss rate is estimated to be very small (less than 10''' ... 10'**), the quality of transmission being 
comparable to that of a high quality ISDN. 

The following happens if a cell is lost (see ITU-T Recommendation 1.363.2 [87]): 

- At least one CPS packet is distorted. 

The distorted CPS packet(s) is/are discarded by the receiver. 

If only one CPS packet is discarded, the upper layer can identify the event by the UUI/SSSAR sequence number, 
and consequently insert a fill sequence of the length of a CPS payload field to the correct place in the bit stream. 
ITU-T Recommendation 1.366.1 [88] (SSSAR) describes that UUI takes value between and 26 for final data 
and value 27 for more data, but UUI should take value 26 for final data considering compatibility with other 
SSCS specifications. When UUI works as sequence number by repetition of 27 and 26, CPS packet payload size 
is equal to half a SDU size. This CPS packet payload size also satisfies the requirement described in subclause 
6.2.1. CPS packet payload size is set by ITU-T Recommendation Q. 2630.1 [89] over lu interface. 

If more than one CPS packets are discarded, the upper layer can identify the event by monitoring the buffer level 
at the ATM/TDM interface or by monitoring the reception of CPS packets with a timer. (The modulo 2 sequence 
number cannot indicate the loss of two consecutive CPS packets). The following figures apply for the 40 octet 
payload field. 

Worst case: 2 packets lost => 2 x 40 octets x 8 bits/octet : 64 kbit/s = 10 ms, i.e. buffer level decreased by 
80 octets. 

Consequently, recovery with fill inserted in the correct place is possible, if the ATM cell jitter (i.e. transmission 
delay variation) is less than 5 ms. With a bigger jitter fill may be inserted in a wrong place in the TDM bit 
stream. 



1 1 a. 3. 3 A interface with IP transport 



The CLEARMODE RTP payload type (see IETF RFC 4040[92]) or Redundant RTP payload for Audio Data as 
specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be used. Transport without 
redundancy shall be supported. Transport with redundancy may be supported. Only the redundancy level 2 and level 3 
are applicable on the AoIP interface. 

Note: The redundancy level is signalled from the MSC server by the Mc interface as negotiated between the 
MSC server with the BSC. 

The data within the CLEARMODE RTP payload type shall be transported with a framing period of 20 ms in a 64 kbit/s 
bit stream and shall be encoded as for the TDM case of the A interface. 

1 1 a.3.4 Nb interface at access side of IWF in a SIP-I based CS CN 

The CLEARMODE RTP payload type shall be used with a framing period of 20 msecs. The data within the 
CLEARMODE RTP payload type shall be transported in a 64 kbit/s bit stream and shall be encoded as for the TDM 
case of the A interface. 

1 1 a.3.5 Nb interface at network side of IWF in a SIP-I based CS CN 

CLEARMODE [92] shall be supported in addition to G.711 [l,x] as RTP payload types. 
The negotiation of payload types is described in Clause 15. 



12 Frame Synchronization 



Potentially two links are involved in the MSC/IWF regarding the need for frame synchronization, i.e. the link towards 
the UE and the link towards the fixed network. The links towards the UE are covered by 3GPP TS 48.020 and 48.060 
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for A/Gb mode and 3GPP TS 25.415 for lu mode. For the link towards the fixed network, the appropriate sections of 
ITU-T Recommendation V-series modem, V.llO, V.120 and PIAFS Recommendations apply. 

12.1 Initial frame synchronization 

12.1.1 Terminating side (towards the UE) 

In lu mode, the terminating side is not synchronous. 

In A/Gb mode, for transparent/non-transparent and interworking to the PSTN or ISDN the interface to the RAN is 
managed as follows. As soon as the outband signalling exchange indicates that the traffic channel is available the 
MSC/IWF will start sending frames with the frame contents set as indicated in subclause 9.2.3.4.1 towards the RAN. 
The MSC/IWF will seek to attain V. 110 or A-TRAU frame synchronization on the incoming data from the RAN. V.llO 
synchronization will be considered to be completed in line with the procedures described in subclause 9.2.3.4.1.1. A- 
TRAU frame synchronization will be considered to be completed in line with the procedures described in subclause 
9.2.3.4.1.2. The incoming data will only be considered valid once the frame synchronization procedure defined in 
subclause 9.2.3.4.1 is complete. For non-transparent interworking to the PSTN or ISDN, the procedures described in 
subclause 9.2.4.10.1 shall be followed. 

1 2.1 .2 Transit side (towards the fixed network) 

12.1.2.1 Interworking to the PSTN 

In the case of interworking to the PSTN the procedures for initial synchronization for the transparent services are 
covered in subclause 9.2.3.4.2 and the non-transparent services in subclause 9.2.4.10.2. 

1 2.1 .2.2 Interworking to the ISDN 

In the case of interworking to the ISDN the procedures for initial synchronization for the transparent services are 
covered in subclause 10.2.3.4.2 and the non-transparent services in subclause 10.2.4.10.4.2. 

12.2 Action on loss of frame synchronization 

The IWF should attempt to recover synchronization as described in the following subsections. If the resynchronization 
attempt fails, the IWF may clear the call. 

1 2.2.1 Loss on the transit side (towards the fixed network) 

If loss of frame synchronization is detected from the fixed network in line with the procedures specified in the ITU-T or 
PIAFS recommendation applicable to the type of interworking (V.l 10, V. 120, PIAFS or V-series modem), then 
re-synchronization is initiated in line with the procedures specified in that recommendation. No change of behaviour of 
the MSC/IWF on the RAN/MSC link is necessary. 

1 2.2.2 Loss on the terminating side (towards the UE) 

In lu mode, the terminating side is not synchronous, so loss of synchronisation is not possible. For T services, frames 
may be lost or arrive irregularly, which handling is implementation dependent. 

In A/Gb mode, if the MSC/IWF detects a loss of frame synchronisation on one or more substreams on the RAN/MSC 
link, the MSC/IWF initiates a re-synchronisation on the substreams in question as specified in the following. 

The MSC/IWF shall detect a loss of V. 1 10 frame synchronisation in line with the rules specified in ITU-T 
Recommendation V.l 10. The MSC/IWF shall detect a loss of A-TRAU frame synchronisation when an A-TRAU frame 
has been received with at least one error in the synchronisation pattern (ref 3GPP TS 48.020). 

If loss of synchronization is detected on the RAN/MSC link then a re-synchronization process should be initiated. 
However for this link to the RAN it is only necessary to search for the frame alignment pattern incoming from the 
RAN. In the case of A-TRAU the synchronisation shall take care of the multiframe alignment according to subclause 
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9.2.3.4.1.2 and the MSC/IWF shall set the control bit UFE (Uplink Frame Error, see 3GPP TS 48.020) in the next 
downlink A-TRAU frame to indicate the framing error to the RAN. 

There shall be no action regarding the outgoing frame towards the RAN, other than to continue sending the rate adapted 
frames made up of the incoming data from the fixed network. During the re-synchronization process data shall continue 
to be sent towards the fixed network via the modem or ISDN (V. 110, V. 120, or PIAFS) TA-function as if the frame 
synchronization were still available. The mapping of the status bits is unchanged during re-synchronization. 

Once synchronization has been re-attained the RLP will recover any possible loss of data on the RAN/MSC link in the 
case of non-transparent services. The indication of UFE will be stopped in the case of A-TRAU. 



13 Call Clearing 



When a call is to be cleared, the MSC/IWF shall handle both the links, towards the UE as well as towards the fixed 
network. 

At the link towards the UE out-band (3GPP TS 24.008) signalling shall be used. Changes in the in-band status bits shall 
not be used to signal call clearing. 

At the link towards the fixed network, the clearing procedures appropriate to the fixed network shall be used, together 
with any additional procedures described in the ITU-T Recommendation applicable to the type of interworking 
(V.llO, V.120, PIAFS or V-series modem). 



14 The A-TRAU Framing Protocols 
14.1 A-TRAU' Protocol 

The A-TRAU' protocol is defined as follows: 

A-TRAU' frames are transmitted in regular intervals of 10ms; 

an A-TRAU' frame consists of two consecutive A-TRAU frames (as defined in 3GPP TS 48.020 [28]) each with 
a length of 320 bit; 

the A-TRAU' protocol is used on a plain 64 kbit/s channel without substreams; 

the same A-TRAU' format is used for the transparent and non-transparent transmission mode; 

in transparent mode the number of data bits in an A-TRAU' frame depend on the user rate only, each user rate 
corresponds to a fixed number of data bits (see below); 

in non-transparent mode A-TRAU' frames contain always complete RLP frames, rate adaptation is performed by 
means of the M2 bit; 

the Ml -bit is used to identify T' and 2"'' frame in both transmission modes. 

14.1.1 Frame layout for the different transparent user rates 

The number of data bits in an A-TRAU' frame depend on the user rate only, each user rate corresponds to a fixed 
number of data bits in an A-TRAU' frame. 

Table 20: A-TRAU' frame layout for transparent user rate 



Date Rate 


Number of data bits per A-TRAU' frame 


33.6 kbit/s 


336 


28.8 kbit/s 


288 
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36 bit data field 1 



36 bit data field 2 



The data bits are inserted in the A-TRAU' frame starting with Dl of Data field 1 of the first A-TRAU frame. The 
unused bits are filled with binary '1'. 

14.1.2 A-TRAU' frame format 

One A-TRAU' frame consists of two consecutive A-TRAU frames. Figure 20 shows the format of one A-TRAU frame. 



Octet number 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 



bit num 



Der 

1 


2 


3 


4 


5 


6 


7 


















































1 


C1 


C2 


C3 


C4 


C5 


Ml 


M2 


Z1 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z2 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


Dig 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z3 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z4 


Dl 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


Die 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z5 


Dl 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


DIG 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z6 


Dl 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z7 


Dl 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 
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D20 


D21 


D22 


D23 


D24 
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D28 


D29 
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D31 


D32 


D33 


D34 


D35 


D36 


Z8 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 
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D33 


D34 


D35 


D36 



36 bit data field 3 



36 bit data field 4 



36 bit data field 5 



36 bit data field 6 



36 bit data field 7 



36 bit data field 8 



Figure 20: A-TRAU 320 bit frame 

Data Bits (Dxx): 

The 288 data bits of an A-TRAU frame are divided in eight fields of 36 bits. 

Control bits (C Bits): 

CI to C4: 

The Control bits CI to C4 define the used data rate. CI to C4 in the first A-TRAU frame indicate the data rate in send 
direction. 
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CI to C4 in the second A-TRAU frame indicate the used data rate in backward direction. This is required for Rate 
Control that is required in uplink direction. For details on Rate Control see 3GPP TS 25.415 [42]. 

Table 21 : A-TRAU' control bits 



CI 


C2 


C3 


C4 


Radio Interface User Rate 


1 





1 


1 


57,6 kbit/s 


1 








1 


43,2 kbit/s 


1 





1 





33,6 kbit/s 


1 











28,8 kbit/s 





1 


1 


1 


14,4 kbit/s 



C5: 

C5 is not used, it is set to binary '1'. 

Bit Ml: 

An A-TRAU' frame is made of two consecutive A-TRAU which build the transport container for 576 data bits. Bit Ml 
is used to determine the order of the A-TRAU frames within an A-TRAU' frame. 

The two Ml bits are referred to as the Frame Start Identifier. The FSI value is 01. These values are assigned to the Ml 
bit as shown below: 

Table 22: Frame Start Identifier 





IVI1 bit 


First A-TRAU frame 





Second A-TRAU frame 


1 



Bit M2: 

The M2 bit is used to indicate 'valid' A-TRAU' frames. The M2 bit in both of the two consecutive A-TRAU frames 
relating to an A-TRAU' frame shall have the same value. 

Transparent mode: 

In transparent mode M2 is clamped to binary '0'. 

Non-transparent mode: 

In non-transparent mode M2 is used for DTX. If DTX is applied, M2 is set to binary '1'. If DTX is not to be applied, M2 
bit is set to binary '0'. The DTX handling is used in both directions for rate adaptation purpose. This means that the 
sending entity will insert 'fill RLP-frames' with DTX set to binary '1' in case no RLP-frame is available. 

Fill frames are also sent in order to adapt the RLP transmission frequency to the AIUR. The ratio between RLP frames 
and "fill" RLP frames is defined in the following table: 

Table 23: RLP transmission frequency 



AIUR 


Ratio between RLP and "fill" RLP 
frames 


57.6 kbit/s 


Only valid frames 


43.2 kbit/s 


3 valid frame followed by 1 "fill" frame 


28.8 kbit/s 


1 valid frame followed by 1 "fill" frame 


14.4 kbit/s 


1 valid frame followed by 3 "fill" frames 



Z bits: 

The bits Zi are used for Framing Pattern Substitution mechanism. This mechanism is defined in 3GPP TS 48.020 [28]. 
Mapping of A-TRAU" frames to PCM time slots: 
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A-TRAU" frames shall be mapped octet aligned to PCM time slots. I.e. bit number to 7 of each octet of an A-TRAU" 
frame shall be mapped to bit number to 7 of the PCM time slot. 

14.2 A-TRAU'" Protocol 

The RLP frame length of 240 bit shall be used. For the transfer of this RLP frame length the A-TRAU"" protocol is 
introduced. An A-TRAU"" frame has the same layout as the A-TRAU" frame and contains two A-TRAU frames. 

One RLP frame with the length of 240 bit is contained in one A-TRAU frame. The A-TRAU"" protocol is only used for 
the non-transparent services. 

In Figure 21, the format of the A-TRAU frame for the RLP frame length of 240 is shown. 

Octet number 



1 

2 

3 

4 | D8 I D9 | d10 | d11 | D12 | D13 | D14 | D15 1 36 bit data field 1 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 



Bit number 
1 


2 


3 


4 


5 


6 


7 
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D9 


D10 


D11 


D12 


D13 


D14 


D15 


Die 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z2 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


Die 


D17 


D18 


Dig 


D20 


D21 


D22 


D23 


D24 


D25 


D2e 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z3 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


DIG 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z4 


D1 


D2 


D3 


D4 


D5 


De 


D7 


D8 


D9 


DIG 


D11 


D12 


D13 


D14 


D15 


Die 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z5 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


DIB 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z6 


D1 


D2 


D3 


D4 


D5 


De 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


Dse 


Z7 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D26 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


D36 


Z8 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


D8 


D9 


D10 


D11 


D12 


D13 


D14 


D15 


D16 


D17 


D18 


D19 


D20 


D21 


D22 


D23 


D24 


D25 


D2e 


D27 


D28 


D29 


D30 


D31 


D32 


D33 


D34 


D35 


Dse 



36 bit data field 2 



36 bit data field 3 



36 bit data field 4 



36 bit data field 5 



36 bit data field 6 



36 bit data field 7 



36 bit data field 8 



Figure 21 : Use of A-TRAU frame for RLP frame size of 240 bits 

Data Bits (Dxx): 

The 288 data bits of an A-TRAU frame are divided in eight fields of 36 bits. 
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Only 240 data bits will be used. The data bits D25 ... D 26 of the data field 7 and the data bits Dl . . . D36 of the data 
field 8 are set to "1" in of transfer of 240 bit long RLP frames. 



Control bits (C Bits): 

CI to C4: 

The Control bits CI to C4 define the used data rate. CI to C4 in the first A-TRAU frame indicate the data rate in send 
direction. 

CI to C4 in the second A-TRAU frame indicate the used data rate in backward direction. This is required for Rate 
Control in uplink direction. 

Table 24: A-TRAU control bits for A-TRAU' 



CI 


C2 


C3 


C4 


Radio Interface User Rate 


1 











28,8 kbit/s 





1 


1 





38,4 kbit/s 





1 





1 


19,2 kbit/s 





1 








9,6 kbit/s 



C5: 

The C5 bit indicates that the A-TRAU"" protocol is used and one A-TRAU frame contains one RLP frame with the 
length of 240 bit. In this case C5 is set binary "0". 



Bit Ml: 

For A-TRAU"" the Ml bit in each A-TRAU frame is always set to 1. 

Bit M2: 

A-TRAU"" protocol is only used in non-transparent mode. 

The M2 is used for DTX. If DTX is applied, M2 is set to binary '1 '. If DTX is not to be applied, M2 bit is set to binary 
'0'. The DTX handling is used in both directions for rate adaptation purpose. This means that the sending entity will 
insert 'fill RLP -frames' with DTX set to binary '1' in case no RLP-frame is available. 

Fill frames are also sent in order to adapt the RLP transmission frequency to the AIUR. The ratio between RLP frames 
and "fill" RLP frames is defined in the following table for the A-TRAU"" protocol: 

Table 25: RLP transmission frequency 



AIUR 


Ratio between RLP and "fill" RLP frames 


38,4 kbit/s 


Each A-TRAU frame is valid 


28,8 kbit/s 


An A-TRAU"" frame witli two valid frames is followed by an A- 
TRAU"" frame containing one valid frame and one fill frame. 


19,2 kbit/s 


Each A-TRAU"" frame contains one valid frame and one fill 
frame. 


9,6 kbit/s 


An A-TRAU"" frame with one valid frame and one fill frame is 
follows by an A-TRAU"" frame containing two fill frames 



Z bits: 

The bits Zi are used for Framing Pattern Substitution mechanism. This mechanism is defined in 3GPP TS 48.020 [28]. 
Mapping of A-TRAU"" frames to PCM time slots: 
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A-TRAU"" frames shall be mapped octet aligned to PCM time slots. I.e. bit number to 7 of each octet of an A-TRAU" 
frame shall be mapped to bit number to 7 of the PCM time slot. 



15 RTP Payload Type Negotiation for Data Calls within 
a SIP-I based CS Core Network 

1 5.1 RTP payload type negotiation at access side of IWF 

For any data call, the SDP offer shall contain a single m-line with only the CLEARMODE payload type (see IETF 
RFC4040 [92]). In addition, the ISUP lAM encapsulated in the INVITE to set up the corresponding call leg shall 
contain TMR UDI. 

1 5.2 RTP payload type negotiation at network side of IWF 

If a call is determined to be a data call other than faxsimile or Modem (i.e. TMR "UDI") by the offerer, the SDP offer 
shall contain a single m-line with only the CLEARMODE payload type (see IETF RFC 4040 [92]). 

If a call is determined to be a faxsimile or Modem call by the offerer, the SDP offer shall contain an m-line including 
only the PCM codec. For faxsimile, the offer may include an additional m-line including the t38 payload type (see ITU- 
T Recommendation T.38 [96] and IETF RFC 3362 [97]). 

If an offerer is not able to determine if a call is a data call or a speech call (TMR "3. 1 kHz Audio"), it shall only offer 
speech codec(s) including the PCM codec. If the PCM codec is offered in combination with other speech codecs, the 
OoBTC procedures in Clauses 6.12 and 9.3 of TS 23.153 [91] are applicable. 

For SCUDIF (see TS 23.172 [83]), the "vnd.3gpp.clearmode" RTP payload type (see Annex C) shall be offered together 
with speech codec(s) in a single SDP m-line. The OoBTC procedures in Clause 9.3 of TS 23.153 [91] are applicable. 
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Annex A (informative): 
SDLs 



The following SDLs are intended to assist in the interpretation of the text in subclause 10.2.2 and are not intended to 
indicate implementation requirements. Therefore these SDLs are informative only. 



Procedure DataFlow_HLR 



Sheetl(l) 



Multiple or single 
numbering scheme? 




Ref. Section 
10.2.2.3 HLR 
Note 4 



Ref. Section 
10.2.2.3 HLR 
Note 2 



Yea 

_L_ 



'Provide Roaming 
Number' includes 
PLMN-BC/HLC or 
ISDN-BC/LLC/HLC 



Ref. Section 
10.2.2.3 HLR 
Note 3a 



'Provide Roaming 
Number' includes 
Stored PLMN-BC/HLC 



f Ref. Section 

10.2.2.3 HLR 
iNote2&3b 



'Provide Roaming 
Number' includes 
PLMN-BC/HLC or 
ISDN-BC/LLC/HLC 



/ Ref. Section 

10.2.2.3 HLR 
lNotela&5 



'Provide Roaming 
Number' includes 
Stored PLMN-BC/HLC 




In exceplhii to thii the BC stored in fiit HLR /.v 
regarded! valid if one (tfthejoftnwtttg t^a^ e^ applies: 
IflTC = UDIfRD! and User Rale = iJ khith !St> 
^Ws and UA^f tfiformatiofi layer 1 protactyl = 
V.lm. UrnXMi and the stared aC Indicates FTM. 
PSAFSoi- Multimedia. 

IflTC ~ 3-1 kHz audio and IherRaif = l^.ltkblt/s 
and Modem Type ^ V.S4 and tlie stoivd BC indicates 
Mtiltimedla. 



I Ref. Section 

10.2.2.3 HLR 
I Note lb 



'Provide Roaming 
Number' sent with No 
PLMN-BC 



Note The SDLs presented here ai'e 
indicative of the pracedures in section 
10-2-2 and are therefore infomiative only 



K 



Figure A.I (Sheet 1 of 1): Procedures in the HLR 
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Procedure DataFlnw MSC VLR. 







^ 






VMKT 



■Hirri|"w:i"- 




iej.j 



ton EAM (PCIHUVLLCT' 



D» ihl M A ^ Onfl 1^ Us tJ IfMV^ EMM ^ ST 

ii-Cidkii i«A 1 Kvhiv] - V.I id. uavMU >fJ «» ibini 

HrW ■ !1 m; «»K>^<1 1 lur FlH • ^ C Ml/i in] M^lMI 
T^ - VM ud Ihi und 1^' udnlH kWlbiBlk 



<^ 






io.il Wi 






1D.M 

vuac 



wji(a:iLjr,«L<:j 



iix:.z 
vwac 



iFAXTHIafTBH 



I 10.1: Vli 

\ Oat 1 4dG 



:SErU?- EC k MOT 



^ftlKltH SCtJ PGKIIDH] hVa lit'' . 
1 1X^2 ud .« li«i¥Gx^ ii£nMn« 



Figure A.2 (Sheet 1 of 1): Procedures in the lUISC/VLR 
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Annex B (informative): 

General mapping of V.24 circuits to channel status bits 

In the data transfer state, status bits SA, SB and X can be used to convey channel control information associated with 
the data bits. Table CI shows the general mapping scheme between the V.24 circuit numbers and the status bits in the 
IWF. A binary corresponds to the ON condition, a binary 1 to the OFF condition. The specific mappings for the 
various PLMN bearer types are given elsewhere in the present document. 

Since the V.24 circuits that are outputs from a DCE are inputs to a DTE (and vice versa), this mapping is the reverse of 
that used in the MT (3GPP TS 27.002, 3GPP TS 27.003). 

For example, CT 109 is an output from the modem in the IWF and maps on to SB towards the MT. In the MT, SB is 
mapped on to CT 109 which is an input to the attached DTE. 

Table B1 : General mapping scheme at the IWF 



Status bit 
direction: UE to IWF 


Status bit 
direction: IWF to UE 


Signal at IWF modem 
interface 


SB 




105 (note 3) 




X(note 1) 


106 




SA 


107 


SA 




108 




SB 


109 


X 




133 (notes 2 and 3) 


NOTE 1 : The condition of X towards the UE may also be affected by the state of any 

transmit buffer in the IWF. 
NOTE 2: The condition of CT 1 33 towards the modem may also be affected by the state of 

any receive buffer in the IWF or layer 2 flow control condition between the MT 

and IWF. 
NOTE 3: CT1 05 and CT1 33 are assigned to the same connector pin on both the standard 

25 pin connector (ISO/IEC 2110 [78]) and the commonly used 9 pin connector 

(annex B). When this pin is used for CT133 at the DTE/IVIT interface then on the 

IVIT side of the interface CT 1 05 is treated as being always in the ON condition. 

SB towards the IWF will therefore also always be ON. 

Similarly, when this pin is being used for CT1 05 then on the MT side of the 

interface CT 1 33 is treated as being always in the ON condition. X towards the 

IWF will therefore also always be ON. 

As circuit 1 33 is used only in duplex operation and circuit 1 05 is used only in half 

duplex operation (which is not supported by the PLMN) there should be no 

conflict. 
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Annex C (normative): 

RTP payload type for SCUDIF in SIP-I based CS core 

network 

C.1 Scope 

This Annex defines the "vnd.3gpp.clearmode" RTP payload type which shall be used within SDP (see IETF RFC 4566 
[98]) to denote the 3G-324.M and the 3G-324.M2 "dummy codecs" defined to indicate a multimedia call for SCUDIF in 
3GPP TS 23.172 [83]. Procedures for the codec negotiation applying these codecs are defined in 3GPP TS 23.172 [83] 
and in Clause 15.2 

C.2 RTP payload Type definition 

The "vnd.3gpp.clearmode" RTP payload type shall have the same PDU format and contents as defined for the 
Clearmode RTP payload type in IETF RFC 4040 [92]. 

The "vnd.3gpp. clearmode" RTP payload type shall be an "audio" media type. 

In addition to the optional "ptime" and "maxptime" parameters, which shall have the same meaning as specified for the 
Clearmode RTP payload type in IETF RFC 4040 [92], the following additional optional MIME parameter is defined: 

"network-initiated-service-change": 

This parameter shall be suppHed for the "3G-324.M2" codec defined in 3GPP TS 23.172 [83]. It shall be omitted for the 
"3G-324.M" codec defined in 3GPP TS 23.172 [83]. No values shall be supplied for this parameter. 

C.3 Describing the RTP payload Type in SDP 

The "vnd.3gpp. clearmode" RTP payload shall be described in SDP (see IETF RFC 4566 [98]) as follows. 

- The MIME type ("audio") shall be used in the SDP "m=" line as the media name 

- A dynamic RTP payload type number shall be used in the SDP "m=" line. 

- The meaning of the dynamic RTP payload type number shall be described by supplying "vnd.3gpp.clearmode" as 

MIME subtype within an SDP "rtpmap" attribute. 

- If supplied, the optional parameter "ptime" shall be encoded as "ptime" SDP attribute. 

- If supplied, the optional parameter "maxptime" shall be encoded as "maxptime" SDP attribute. 

- If supplied, the optional parameter "network-initiated-service-change" shall be encoded within the "fmtp" SDP 

attribute. No values for the parameter shall be supplied. 

C.4 SDP Offer-Answer considerations 

The "network-initiated-service-change" is a declarative parameter. If an "vnd.3gpp. clearmode" RTP payload type with 
an associated "network-initiated-service-change" parameter is included in an SDP "m="-line in an SDP offer, this RTP 
payload type shall either be rejected by excluding it from the "m="-line in the SDP answer, or the RTP payload type 
shall be included in the answer and the associated "network-initiated-service-change" parameter shall then be supplied 
in the answer. 
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C.5 SDP Example 



The following example shows an SDP offer during the setup of a SCUDIF call, where Multimedia is the preferred 
encoding and the network initiated service change is supported. AMR and PCM are offered as speech codecs for a 
fallback. 

m=audio 12345 RTP/AVP 97 98 99 
a=rtpmap : 97 vnd . 3gpp . clearmode/SOOO 
a=rtpmap : 98 vnd . 3gpp . clearmode/SOOO 
a=fmtp : 98 network-initiated-service-change 
a=rtpTnap:99 AMR/8000/l 
a=3gOoBTC 
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Annex D (informative): 

lANA registration information for RTP payload types for 

SCUDIF in SIP-I based CS core network 

D.1 Introduction 

This Annex provides information required for the registration of the "vndJgpp.clearmode" RTP payload type at lANA. 

Editor's note: MCC is requested to perform this registration on behalf of 3GPP at 
http://www.iana.org/cgi-bin/mediatypes.pl 

D.2 lANA Registration information 
D.2.1 Media Type Name 

audio 

D.2.2 Subtype Name 

vnd . 3 gpp . clearmode 

D.2. 3 Required parameters 

none 

D.2. 4 Optional parameters 

"ptime" gives the length of time in milliseconds represented by the media in a packet, as described in RFC 4566 [98]. 

"maxptime" represents the maximum amount of media, which can be encapsulated in each packet, expressed as time in 
milliseconds, as described in IETF RFC 4566 [98]. 

"network-initiated-service-change" denotes if a network initiated servive change is supported or applied. It shall be used 
according to the rules in 3GPP TS 29.007 and 3GPP TS 23.172 [83]. No values shall be supplied for this parameter 

D.2. 5 Encoding considerations 

Framed encoding. 

D.2. 6 Security considerations 

See Section 6 of RFC 4040 [92] 

D.2. 7 Interoperability considerations 

none 



D.2. 8 Published specification 

3GPP TS 29.007. 
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D.2.9 Applications winicin use tinis media type 

Service change and UDI/RDI Fallback (SCUDIF), as defined in 3GPP TS 23.172 [83] 

D.2.10 Additional information 

This type is only defined for transfer via RTP. 

D. 2. 10.1 Magic number(s) 

none 

D.2.10.2 File extension(s) 

none 

D.2.10.3 Macintosh File Type Code(s 

none 



D.2.1 0.2 Object Identifier(s) or OID(s) 

none 

D.2.11 Intended usage 

Limited use. 

This RTP payload type will only be applied within a 3GPP SIP-I based circuit switched core network, as specified in 
3GPPTS 23.231 [99] 

D.2.1 2 Other Information/General Comment 

none 

D.2. 1 3 Person to contact for further information 

3GPP Specifications Manager 
3gppGontact@etsi.org 
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Annex E (informative): 
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